Date:	Fri, 1 Jan 2010 14:57:01 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	"Serge E. Hallyn" <serue@...ibm.com>
Cc:	Bryan Donlan <bdonlan@...il.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"Andrew G. Morgan" <morgan@...nel.org>,
	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

> 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.

You assume firstly that it matters. If it doesn't matter and people don't
want to mix SELinux etc with weird little hacks then the problem doesn't
really arise anyway. If people do want to stack them then yes they'll
have to do the work. Diddums, thats how it works, and filling the kernel
with crap shortcuts just makes a bigger mess longer term and leaves a
huge mess to sort out.

There are lots of trivial ways to implement a fast lookup per security
context. The only real problem is figuring out how much space is needed
and that's fairly trivial to do providing you don't try and be clever and
reclaim slots unloading modules

You just need void * security and an offset allocated per security module
as its registered. We've even got library code to hand those out nicely
alloc and free them (leaving holes on unload and refilling on reload)

Then it all comes out as

lsm_context = (struct my_lsm_context *)(task->security + lsm->offset)

whoopee 1 clock.

You pay a cost at LSM load time (which is extremely rare) to update all
the tasks and introduce them to the LSM but you need to do that anyway to
initialise your LSM state for each task.

If people were serious about doing the work right rather than just trying
to dump their pet neat idea into the kernel with no care about the cost
I'd expect to see patches for sharing ->security, LSM stacking first.
They are not hard technically.

There are real issues about what it *means* to stack LSM modules
semantically but thats a problem for the admin not the kernel so it's not
a "hard" problem programming wise.

> 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

Should be a bitflag - then you can also fix some of the locking questions
- the current code really doesn't consider locking issues at all - which
needs fixing.

> or something like it next to the
> 
> #ifdef CONFIG_SECURITY
> 	void *security;
> #endif

And 148 other #defines later it'll be a joyous mess.

Its always easier short term to pee in the pond than install a toilet -
it's just not a good long term plan.

--
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