--- Andrew Morgan <[EMAIL PROTECTED]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Serge E. Hallyn wrote: > > Meanwhile, any chance you would get some time to implement the cap_bset > > vs fcaps change you wanted? I'd have to look at my checklist to be > > sure, but I think that, a version of this patch, and then somehow > > addressing James' request for config-able forward compability of > > capabilities may finish off the feature request list (as it currently > > stands at least). > > There are four things I'd like to do (they were the things not mentioned > in item #8 in a long-ago email): > > 0. fix the implementation of cap_setpcap. It is supposed to mean 'this > process can raise capabilities, outside its permitted set, in _its own_ > inheritable set'. What is currently implemented is that this capability > gives a so-endowed process the ability to alter any/all the capabilities > of any/all other processes. I consider this a hack created to overcome > the lack of filesystem capabilities support. Now we have filesystem > support, we don't need the hack.
I don't think that limiting it to the inheritable set is necessary. Otherwise, I agree on all counts. > 1. make cap_bset a per-process thing which, like the inheritable set, > is copied unchanged through fork() and exec(). The idea here is that the > un*x model naturally contains processes as trees, and bounding such a > tree at its root is a more appropriate (you can reason about it) > security model for unix than having a global bound like this. I think this would be a good refinement, but later, after people start to get used to file based capabilities. > 2. replace the global secure-bits with a per-process set. The idea here > is that different process trees can operate with root as the super-user, > or with capabilities, or both. As with 1, this is a better fit for un*x > than a (hard to use) global flag. This is an idea we toyed with some time ago. It might make some applications that are stubbornly setuid-root easier to deal with. > 3. Get rid of all the 'emulate root with capabilities' support. I've > come to believe that this emulation was basically a mistake born of the > fact that there was no file-system capability support. Yup. > I'm not sure how controversial these changes will be. > > I have started to look at 3, but can look at 1 first if you consider it > more urgent. 0, 3, 2, 1 if you care about my priorities. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
