On Fri, 01 Feb 2008 00:11:37 -0800 "Andrew G. Morgan" <[EMAIL PROTECTED]> wrote:
> [This patch represents a no-op unless CONFIG_SECURITY_FILE_CAPABILITIES > is enabled at configure time.] Patches like this scare the pants off me. I'd have to recommend that distributors not enable this feature (if we merge it) until they have 100% convinced themselves that it is 100% correct. Can you please provide us with a reprise of - what was the bug which caused us to cripple capability inheritance back in the days of yore? (Some sendmail thing?) - Why was that security hole considered unfixable? - How does this change avoid reintroducing that hole? > Filesystem capability support makes it possible to do away with > (set)uid-0 based privilege and use capabilities instead. That is, with > filesystem support for capabilities but without this present patch, > it is (conceptually) possible to manage a system with capabilities > alone and never need to obtain privilege via (set)uid-0. > > Of course, conceptually isn't quite the same as currently possible > since few user applications, certainly not enough to run a viable > system, are currently prepared to leverage capabilities to exercise > privilege. Further, many applications exist that may never get > upgraded in this way, and the kernel will continue to want to support > their setuid-0 base privilege needs. Are you saying that plain old setuid(0) apps will fail to work with CONFIG_SECURITY_FILE_CAPABILITIES=y? > Where pure-capability applications evolve and replace setuid-0 > binaries, it is desirable that there be a mechanisms by which they > can contain their privilege. In addition to leveraging the per-process > bounding and inheritable sets, this should include suppressing the > privilege of the uid-0 superuser from the process' tree of children. > > The feature added by this patch can be leveraged to suppress the > privilege associated with (set)uid-0. This suppression requires > CAP_SETPCAP to initiate, and only immediately affects the 'current' > process (it is inherited through fork()/exec()). This > reimplementation differs significantly from the historical support for > securebits which was system-wide, unwieldy and which has ultimately > withered to a dead relic in the source of the modern kernel. > > With this patch applied a process, that is capable(CAP_SETPCAP), can > now drop all legacy privilege (through uid=0) for itself and all > subsequently fork()'d/exec()'d children with: > > prctl(PR_SET_SECUREBITS, 0x2f); > > Applying the following patch to progs/capsh.c from libcap-2.05 > adds support for this new prctl interface to capsh.c: > > ... > > Acked-by: Serge Hallyn <[EMAIL PROTECTED]> Really? I'd feel a lot more comfortable if yesterday's version 1 had led to a stream of comments from suitably-knowledgeable kernel developers which indicated that those developers had scrutinised this code from every conceivable angle and had declared themselves 100% happy with it. Maybe I'm over-reacting here. Feel free to tell me if I am :) But as I told you outside the bathroom today: I _really_ don't want to read about this patch on bugtraq two years hence. - 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
