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. - 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
