Message-ID: <551280e50912311020x2bdc5b1o699a601f67b91662@mail.gmail.com>
Date:	Thu, 31 Dec 2009 10:20:18 -0800
From:	"Andrew G. Morgan" <morgan@...nel.org>
To:	"Serge E. Hallyn" <serue@...ibm.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Bryan Donlan <bdonlan@...il.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Benny Amorsen <benny+usenet@...rsen.dk>,
	Michael Stone <michael@...top.org>,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	Andi Kleen <andi@...stfloor.org>, David Lang <david@...g.hm>,
	Oliver Hartkopp <socketcan@...tkopp.net>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Valdis Kletnieks <Valdis.Kletnieks@...edu>,
	Evgeniy Polyakov <zbr@...emap.net>,
	"C. Scott Ananian" <cscott@...ott.net>,
	James Morris <jmorris@...ei.org>,
	Bernie Innocenti <bernie@...ewiz.org>,
	Mark Seaborn <mrs@...hic-beasts.com>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	Américo Wang <xiyou.wangcong@...il.com>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	Samir Bellabes <sam@...ack.fr>,
	Casey Schaufler <casey@...aufler-ca.com>,
	Pavel Machek <pavel@....cz>, Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [RFC][PATCH v3] Unprivileged: Disable raising of privileges

Why not implement this as another securebit? So far as I can see the
whole thing can be implemented in the capability LSM.

What is less clear to me is whether per-process 'disabling of setuid
bits on files' should force mandatory disabling of file capabilities.
It seems as if disabling the transition of one luser to another luser
through a setuid executable is something distinct from privilege
escalation.

Since there is already independent support for disabling file
capabilities (the privilege escalation part), I see these two
mechanisms as separable.

Cheers

Andrew

On Thu, Dec 31, 2009 at 9:52 AM, Serge E. Hallyn <serue@...ibm.com> wrote:
> Quoting Alan Cox (alan@...rguk.ukuu.org.uk):
>> > I see this as being a security-model agnostic API - the reason being,
>>
>> Thats what everyone else says about their security model too
>
> LOL
>
>> > the application is specifying a policy for itself that has meaning in
>> > all existing security models, and which does not require administrator
>> > intervention to configure. Rather than reimplementing this for each
>> > security model, it's far better to do it just once. Moreover, by
>> > having a single, common API, the application can state the general
>> > policy "I will never need to gain priviliges over exec" without
>> > needing to know what LSM is in use.
>>
>> So it can sit in the security hooks and stack.
>>
>> > The future goal of this API is to allow us to relax restrictions on
>> > creating new namespaces, chrooting, and otherwise altering the task's
>> > environment in ways that may confuse privileged applications. Since
>>
>> All of which are security policy, general purpose and frequently part of
>> the main LSM module loaded - in other words it's nothing of the sort when
>> it comes to being separate. Its just another magic interface hook, and as
>> I think the history of capability stuff in kernel shows it doesn't work
>> that way.
>>
>> > security hooks are all about making the existing security restrictions
>> > _stricter_, it's not easy to later relax these using the security hook
>> > model. And once we put in the general requirement that "this task
>> > shall never gain privilege", it should be safe to relax these
>> > restrictions for _all_ security models.
>>
>> In which case the hooks can be tweaked. It's an interface it can be
>> tuned  - and has been - eg for Tomoyo.
>>
>> > In short, this is something which is meaningful for all existing LSMs
>>
>> But is it - and if its combined with 500 other similar hooks and a set of
>> system policies can you even work out the result ?
>>
>> > restrictions later, it doesn't make sense to put it in a LSM as they
>> > stand now.
>>
>> And it certainly doesn't make sense to add this and the several hundred
>> other variants of this "can't open sockets, can't mount, can't this,
>> can't that ...." stuff continually being suggested by randomly extending
>> other unrelated interfaces.
>>
>> Look up the sendmail security archive and you'll even find examples where
>> enforcing extra security on setuid *caused* security problems to show up
>> that were basically impossible to hit otherwise.
>
> That's exactly what we're trying to avoid :)  But I'm personally not
> against making this an LSM.  As you say:
>
>> We have a security system, with a set of interfaces for attaching
>> security models, please stop trying to go round the back of the kernel
>> design because you can't be bothered to do the required work to do the
>> job right and would rather add more unmaintainable crap all over the
>> place.
>>
>> Yes it might mean the hooks need tweaking, yes it probably means the
>
> Yes, and in particular, we'll need to do something about data
> ->security annotations, since, if we make this an LSM, then we can't
> use a per-thread flag.
>
> This feature is used during exec and ptrace, not on hot-paths, so
> dereferencing task->security would be fine.  But finding a way to
> multiplex task->security so it can be used by Eric's nosuid lsm,
> Michael's disablenetwork LSM, and SELinux/smack/apparmor, that
> will likely take months, and, history shows, may never happen.
>
>> people who want these need to do some trivial stacking work, but if as
>> many people are actually really interested as are having random 'lets add
>> a button to disable reading serial ports on wednesday' ideas there should
>> be no shortage of people to do the job right.
>
> Eric, the thing is, once an API goes upstream, we can't change it,
> but in contrast we can change how task->security is used at any time.
> So I'd suggest just adding
>
> #ifdef CONFIG_SECURITY_NOSUID
>        short nosuid;
> #endif
>
> or something like it next to the
>
> #ifdef CONFIG_SECURITY
>        void *security;
> #endif
>
> in struct cred and doing that for a first go.  You could
> share that field with Michael's disablenetwork, or not if you
> prefer - either way, it keeps you and SELinux out of each other's
> ways.
>
> -serge
>
--
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