Message-Id: <20080201002837.d84fc029.akpm@linux-foundation.org>
Date:	Fri, 1 Feb 2008 00:28:37 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	"Andrew G. Morgan" <morgan@...nel.org>
Cc:	Linux Security Modules List 
	<linux-security-module@...r.kernel.org>,
	linux-kernel@...r.kernel.org, "Serge E. Hallyn" <serue@...ibm.com>
Subject: Re: [PATCH] per-process securebits

On Fri, 01 Feb 2008 00:11:37 -0800 "Andrew G. Morgan" <morgan@...nel.org> 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 <serue@...ibm.com>

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists