Messages in this thread | ![/](/images/icornerl.gif) | | Date | Tue, 21 Oct 2003 11:24:17 -0700 | From | Andy Lutomirski <> | Subject | Re: posix capabilities inheritance |
| |
I agree with these problems, but I think the proper fix is complicated. AFAICT, POSIX capability evolution, as specified by whatever draft it was, is broken, so the hacks in prepare_binprm (cap_bprm_set_security in 2.6) are needed to avoid security problems. Aside from the fact that non-inheritable-by-default makes little sense (and requires root to get capabilities re-added from the file _permitted_ set), POSIX cap evolution has some other problems:
1. Can a process have capabilities in its inheritable set and not in its permitted set? POSIX allows such processes to be created (pI = pP = full, then execute (fI = 0, fP = 0). Nevertheless, its pP evolution rule assumes that this never happens (pI capabilities can reappear).
2. If a process has pE < pP (i.e. some caps disabled, e.g. uid=0, euid!=0), and exec's fE=full, then its capabilities get re-enabled. This seems like a pretty serious breakage of userspace.
I have a possible fix to these issues at <http://www.stanford.edu/~luto/linux-fscap/> -- CONFIG_FS_CAPS (in cap-1-fscap.patch) changes the capability evolution rules slightly to make them (IMHO) both safe and sensible, as well as removing the ugly hackage in set_security. This will allow your capabilities to persist through exec(). The second patch (cap-2-ext3.patch) adds file capabilities to ext3. Both are tested on 2.6.0-test6, and they apply with fuzz and compile (but not tested yet) on -test8. (These are different from my last attempt at this -- they are much closer to POSIX semantics.)
Unfortunately, I think it's too late to include these in 2.6.0.
Andy
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |