On Sun, Dec 2, 2012 at 10:35 AM, Andy Lutomirski <l...@amacapital.net> wrote: > 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.
Have you tried adding fI of cap_net_raw to the file to be executed? Cheers Andrew > > 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/
