Quoting Andrew Morgan ([EMAIL PROTECTED]): > -----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'.
A few clarification questions: Process p1 is calling capsetp(3) on p2. p2 may or may not equal p1. Are you saying p1 may raise capabilities in p2 so long as they are in p1's inheritable set, or so long as they are in p2's? > 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. > > 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. Actually this is more useful than I'd been thinking. I use various non-wheel accounts to run crappy programs i don't trust. Being able to have pam not just chroot them and give private /tmp, but also set their cap_bset so they can't even run setuid or filecap programs sounds good. > 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. Good, I like this. How do you intend to authorize setting the secure-bit? > 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. > > I'm not sure how controversial these changes will be. Most of them shouldn't affect anyone who doesn't opt to make use of them, so I would expect the main challenge to be showing that current subtle but expected behaviors are not adversely affected. > I have started to look at 3, but can look at 1 first if you consider it > more urgent. I don't know what you mean by 'getting rid of emulate root with capabilities'. You mean you want to re-introduce the special-casing of uid 0 all over the place, alongside capability checks, depending on the per-process secure-bits? (I assume that's not what you mean) 1 is certainly of more interest to me, but I guess I can't call it urgent :) thanks, -serge - 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
