Date:	Tue, 8 Jan 2013 20:12:48 +1100 (EST)
From:	James Morris <jmorris@...ei.org>
To:	Casey Schaufler <casey@...aufler-ca.com>
cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	LSM <linux-security-module@...r.kernel.org>,
	LKLM <linux-kernel@...r.kernel.org>,
	SE Linux <selinux@...ho.nsa.gov>,
	John Johansen <john.johansen@...onical.com>,
	Eric Paris <eparis@...hat.com>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	Kees Cook <keescook@...omium.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v12 0/9] LSM: Multiple concurrent LSMs

On Mon, 7 Jan 2013, Casey Schaufler wrote:

> There has been an amazing amount of development in system security
> over the past three years. Almost none of it has been in the kernel.
> One important reason that it is not getting done in the kernel is
> that the current single LSM restriction requires an all or nothing
> approach to security. Either you address all your needs with a single
> LSM or you have to go with a user space solution, in which case you
> may as well do everything in user space.

This sounds like a very spurious argument.  If the development is better 
done in userspace, then do it there.

There's no way to address all your security needs with an LSM in any case, 
for any practical system.  LSM is an API for making security decisions 
about kernel flow, usually as part of implementing access control 
mechanisms.  It is not meant to provide any kind of total security 
solution, and the argument that you can't do some security in userspace is 
totally illogical.

Development should be done in userspace unless it must be done in the 
kernel.

> Multiple concurrent LSMs allows a system to be developed incrementally
> and to combine a variety of approaches that meet new and interesting
> needs. It allows for systems that are based on an LSM that does not
> meet all of the requirements but that can be supplemented by another
> LSM that fills the gaps. It allows an LSM like Smack that implements
> label based access controls to remain true to its purpose even in the
> face of pressure to add controls based on other mechanisms.
> 
> I have had requests for running Smack and AppArmor together Tetsuo has
> long had need to put SELinux and TOMOYO on the same box. Yama was
> recently special cased for stackability.

I'd say we need to see the actual use-case for Smack and Apparmor being 
used together, along with at least one major distro committing to support 
this.

Yama is special-cased and can stay that way.

SELinux and Tomoyo together makes no sense to me, and similarly, I would 
like to see the specific use-case for it and distro commitment to support 
it.

> We are looking at security from different directions than ever before.
> What good is a UID on a cell phone? I hear complaints about Android's
> "abuse" of the UID. 

What is the UID issue and how does LSM stacking address it?

> With the option of independent groups creating smallish LSMs and 
> integrating them by stacking we have the ability to make the security 
> systems modern devices require using a architecturally clean model 
> rather than hijacking existing mechanisms that work a little bit like 
> what you want to do.

This is speculative.

> 
> I used to believe in a single, integrated security module that addressed
> all the issues. Now that Linux is supporting everything from real time
> tire pressure gauges in tricycles to the global no-fly list that just
> doesn't seem reasonable. We need better turn around on supplemental 
> mechanisms. That means collections of smaller, simpler LSMs instead of
> monoliths that only a few select individuals or organizations have any
> hope of configuring properly.

If you're trying to say that only a few select individuals or orgs can 
configure things like SELinux and AppArmor properly, you're wrong, and the 
evidence for that is overwhelming.

Also, are you saying that security mechanisms are inherently easier to 
configure if they're composed from a variety of distinct modules vs. a 
monolithic scheme? 



-- 
James Morris
<jmorris@...ei.org>
--
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