|| ||Andrew Morton <email@example.com>|
|| ||"Andrew G. Morgan" <firstname.lastname@example.org>|
|| ||Re: [PATCH] per-process securebits|
|| ||Fri, 1 Feb 2008 00:28:37 -0800|
|| ||Linux Security Modules List
email@example.com, "Serge E. Hallyn" <firstname.lastname@example.org>|
On Fri, 01 Feb 2008 00:11:37 -0800 "Andrew G. Morgan" <email@example.com> 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%
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
> 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 <firstname.lastname@example.org>
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@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html