Quoting Andrew G. Morgan ([EMAIL PROTECTED]): > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Andrew, > > Just to be clear, I'm not sure I agree that I'm hiding anything! > > I've tried very hard to limit this functionality to only being enabled > if the still experimental LSM CONFIG_SECURITY_FILE_CAPABILITIES is yes. > I've also arranged for all of the relevant support code to be inside an > LSM. > > However, I'll do as you say - extend the comment and fix the thinko > pointed out by Serge, and resubmit to more than the LSM list.
Cool, I'd certainly say it's ready, and please feel free to add Acked-by: Serge Hallyn <[EMAIL PROTECTED]> at this point. Of course Andrew Morton's fears are not uncalled for, the whole trouble with subtle security interactions is that they're subtle :) and easy to miss. For what it's worth I'll run a few ltp tests against your next version and try to verify that there are no changes, and no changes when composed with selinux. thanks, -serge > > Cheers > > Andrew > > Andrew Morton wrote: > | On Wed, 30 Jan 2008 23:02:30 -0800 "Andrew G. Morgan" > <[EMAIL PROTECTED]> wrote: > | > |> With filesystem capabilities it is now possible to do away with > |> (set)uid-0 based privilege and use capabilities instead. > |> > |> Historically, this was first attempted with a kernel-global set of > |> securebits. That implementation, however, proved problematic, and has > |> slowly whithered in the kernel. Prior to this patch, there remained no > |> interface for manipulating the securebits - and thus no interface for > |> suppressing root as all-capable. > |> > |> This patch reimplements securebits, with bit locking, as a per-process > |> value. (To avoid increasing the per-task footprint of this change, > |> I've merged the implementation of the per-process keep_capabilities > |> bit with the per-process securebits value.) > |> > |> A process can now drop all legacy privilege (through uid=0), for > |> itself and all of its fork()'d/exec()'d children with: > |> > |> prctl(PR_SET_SECUREBITS, 0x2f); > |> > | > | This is the sort of patch which strikes terror into many hearts. Please, > | it cannot be hidden over on the lsm list. I'll assume that this > version is > | an rfc/rfr for now and will cheerily delete it. > | > | For the next version, please do circulate it more widely. It will > need careful > | explanation and review. > | > | I think it would be useful for this patch's changelog to give us a little > | recap of what went wrong with capabilities, if that's possible (and if > it's > | relevant). What was the bug which caused us to cripple capability > | inheritance (some sendmail thing?) and why was that bug considered > unfixable > | at the time and by what means does this new code avoid the same old bug? > | > | A bit more changelog-for-dummies would be nice, too. This particular > dummy > | doesn't understand why/how fs-caps made it possible for us to start using > | capabilities properly. > | > | And last, but by no means least: s/whither/wither/ ;) > | > | Thanks. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.6 (GNU/Linux) > > iD8DBQFHofxO+bHCR3gb8jsRAvc5AJwPa2+mcPg+mZDsDaXnhGunQCYKdwCgkuG6 > 1UUWHCnsYZOXEPOPjRimKN8= > =aE7E > -----END PGP SIGNATURE----- > - > 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 - 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
