Quoting Jan Engelhardt ([EMAIL PROTECTED]): > > On Oct 23 2007 10:20, Serge E. Hallyn wrote: > > > >Once the per-process capability bounding set is accepted > >(http://lkml.org/lkml/2007/10/3/315) you will be able to do something > >like: > > > > 1. Create user 'jdoe' with uid 0 > > UID 0 is _not_ acceptable for me.
I'm aware. > > 2. write a pam module which, when jdoe logs in, takes > > CAP_NET_ADMIN out of his capability bounding set > > 3. Now jdoe can log in with the kind of capabilities subset > > you describe. > > It is not that easy. > CAP_DAC_OVERRIDE is given to the subadmin to bypass the pre-security > checks in kernel code, and then the detailed implementation of > limitation is done inside multiadm. You mean the read/write split? > This is not just raising or lowering capabilities. Nope, but it's related, and as I pointed out below it fits in pretty nicely. > >It's not a perfect solution, since it doesn't allow jdoe any way at all > >to directly execute a file with more caps (setuid and file capabilities > >are subject to the capbound). So there is certainly still a place for > >multiadm. > > A normal user can execute suid binaries today, and so can s/he with mtadm. > I do not see where that will change - it does not need any caps atm. And he will still be able to *run* the suid binary, but if cap_bound is reduced he won't be able to use capabilities taken out of the bounding set, multiadm loaded or not. -serge - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/