[lkml]   [2013]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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

> 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

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

> 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

 \ /
  Last update: 2013-01-08 11:01    [W:0.178 / U:5.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site