Re: [RFC][PATCH v3] Unprivileged: Disable raising of privileges [LWN.net]

From:		Alan Cox <alan-AT-lxorguk.ukuu.org.uk>
To:		ebiederm-AT-xmission.com (Eric W. Biederman)
Subject:		Re: [RFC][PATCH v3] Unprivileged: Disable raising of privileges
Date:		Wed, 30 Dec 2009 23:00:42 +0000
Cc:		"Serge E. Hallyn" <serue-AT-us.ibm.com>, "Andrew G. Morgan" <morgan-AT-kernel.org>, Bryan Donlan <bdonlan-AT-gmail.com>, Benny Amorsen <benny+usenet-AT-amorsen.dk>, Michael Stone <michael-AT-laptop.org>, linux-kernel-AT-vger.kernel.org, netdev-AT-vger.kernel.org, linux-security-module-AT-vger.kernel.org, Andi Kleen <andi-AT-firstfloor.org>, David Lang <david-AT-lang.hm>, Oliver Hartkopp <socketcan-AT-hartkopp.net>, Herbert Xu <herbert-AT-gondor.apana.org.au>, Valdis Kletnieks <Valdis.Kletnieks-AT-vt.edu>, Evgeniy Polyakov <zbr-AT-ioremap.net>, "C. Scott Ananian" <cscott-AT-cscott.net>, James Morris <jmorris-AT-namei.org>, Bernie Innocenti <bernie-AT-codewiz.org>, Mark Seaborn <mrs-AT-mythic-beasts.com>, Randy Dunlap <randy.dunlap-AT-oracle.com>, AmÃ©rico Wang <xiyou.wangcong-AT-gmail.com>, Tetsuo Handa <penguin-kernel-AT-i-love.sakura.ne.jp>, Samir Bellabes <sam-AT-synack.fr>, Casey Schaufler <casey-AT-schaufler-ca.
Archive-link:		Article, Thread

On Wed, 30 Dec 2009 13:36:57 -0800
ebiederm@xmission.com (Eric W. Biederman) wrote:

> Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> 
> >> Added bprm->nosuid to make remove the need to add
> >> duplicate error prone checks.  This ensures that
> >> the disabling of suid executables is exactly the
> >> same as MNT_NOSUID.
> >
> > Another fine example of why we have security hooks so that we don't get a
> > kernel full of other "random security idea of the day" hacks.
> 
> Well it comes from plan 9.  Except there they just simply did not
> implement suid.  What causes you to think dropping the ability
> to execute suid executables is a random security idea of the day?

Well to be fair its random regurgitated security idea of every year or
two.

More to the point - we have security_* hooks so this kind of continuous
security proposal turdstream can stay out of the main part of the kernel.

Cleaning up the mechanism by which NOSUID is handled in kernel seems a
good idea. Adding wacky new prctls and gunk for it doesn't, and belongs
in whatever security model you are using via the security hooks.

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Log in to post comments)