On Sun, Dec 2, 2012 at 9:21 AM, Andrew G. Morgan <mor...@kernel.org> wrote: > There is a fairly well written paper ;-) explaining how things are > supposed to work: > > http://ols.fedoraproject.org/OLS/Reprints-2008/hallyn-reprint.pdf > > The inheritable set is not intended to work the way you seem to want. > Naive inheritance like that is quite explicitly the opposite of what > was designed.
I'm aware that the system was designed, or perhaps evolved, to prevent users with uid != 0 from inheriting capabilities unless vfs inheritable caps are granted on a per-file basis. I want a way around that -- I want to mix non-root, capabilities, and exec. This is damn near impossible right now if I don't have CAP_SETFCAP or root's explicit, per-program cooperation. CAP_SETFCAP is essentially equivalent to "let me do anything". As it stands, using something like pam_cap to grant a user cap_net_raw is useless -- that user can't use the privilege because (unless uid == 0) the privilege will never end up in the permitted set. I want to come up with a way to change this that will, convincingly, not open up any new security holes. The current concept of process inheritable capabilities seems so vague and so oddly defined that I'm not sure I want to touch it. In an ideal world, I'd want pI <= pP and fP <= fI to be invariants, and I'd like programs without vfs caps set to have fI = <everything>. Making this change will surely break something, though. I'm looking for ideas. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/