From: John Johansen <john.johansen@canonical.com>
To: James Morris <jmorris@namei.org>
Cc: Casey Schaufler <casey@schaufler-ca.com>,
Stephen Rothwell <sfr@canb.auug.org.au>,
LSM <linux-security-module@vger.kernel.org>,
LKLM <linux-kernel@vger.kernel.org>,
SE Linux <selinux@tycho.nsa.gov>, Eric Paris <eparis@redhat.com>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Kees Cook <keescook@chromium.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH v12 0/9] LSM: Multiple concurrent LSMs
Date: Tue, 08 Jan 2013 12:40:39 -0800 [thread overview]
Message-ID: <50EC8447.1000301@canonical.com> (raw)
In-Reply-To: <alpine.LRH.2.02.1301081942030.24212@tundra.namei.org>
On 01/08/2013 01:12 AM, James Morris wrote:
> 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.
>
>
Ubuntu is very interested in stacking
next prev parent reply other threads:[~2013-01-08 20:40 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-08 1:54 [PATCH v12 0/9] LSM: Multiple concurrent LSMs Casey Schaufler
2013-01-08 1:54 ` Casey Schaufler
2013-01-08 2:09 ` [PATCH v12 1/9] " Casey Schaufler
2013-01-08 2:09 ` Casey Schaufler
2013-01-08 2:09 ` [PATCH v12 2/9] " Casey Schaufler
2013-01-08 2:09 ` Casey Schaufler
2013-01-08 2:09 ` [PATCH v12 3/9] " Casey Schaufler
2013-01-08 2:09 ` Casey Schaufler
[not found] ` <201301092211.CGF18746.LMOHJFOOFQtVSF@I-love.SAKURA.ne.jp>
2013-01-09 16:26 ` Casey Schaufler
[not found] ` <50EE9BAE.5010101@canonical.com>
[not found] ` <201301102159.JAE81243.tOFLQVOMHSJOFF@I-love.SAKURA.ne.jp>
[not found] ` <50EEBD8B.2090000@canonical.com>
2013-01-10 16:20 ` Casey Schaufler
[not found] ` <201301212142.FGF86433.OVQJFMHFLtFSOO@I-love.SAKURA.ne.jp>
2013-01-21 22:31 ` Casey Schaufler
[not found] ` <201301220819.AFB21360.OFOQHJFSFVtLMO@I-love.SAKURA.ne.jp>
2013-01-21 23:45 ` Casey Schaufler
[not found] ` <201301221009.JDB30838.tFFMVFLOQJSOOH@I-love.SAKURA.ne.jp>
2013-01-22 2:10 ` Casey Schaufler
[not found] ` <201301221623.JIH35408.LFSJQFOFOOHVMt@I-love.SAKURA.ne.jp>
2013-01-22 19:43 ` Casey Schaufler
[not found] ` <201301232030.HAH52121.VFtOSLHQFJOOMF@I-love.SAKURA.ne.jp>
2013-01-23 16:18 ` Casey Schaufler
2013-01-08 2:09 ` [PATCH v12 4/9] " Casey Schaufler
2013-01-08 2:09 ` Casey Schaufler
2013-01-08 2:09 ` [PATCH v12 5/9] " Casey Schaufler
2013-01-08 2:09 ` Casey Schaufler
2013-01-08 2:09 ` [PATCH v12 6/9] " Casey Schaufler
2013-01-08 2:09 ` Casey Schaufler
2013-01-08 2:09 ` [PATCH v12 7/9] " Casey Schaufler
2013-01-08 2:09 ` Casey Schaufler
2013-01-08 2:09 ` [PATCH v12 8/9] " Casey Schaufler
2013-01-08 2:09 ` Casey Schaufler
2013-01-08 2:09 ` [PATCH v12 9/9] " Casey Schaufler
2013-01-08 2:09 ` Casey Schaufler
2013-01-08 3:01 ` [PATCH v12 0/9] " Stephen Rothwell
2013-01-08 3:59 ` Stephen Rothwell
2013-01-08 4:11 ` Casey Schaufler
2013-01-08 4:11 ` Casey Schaufler
2013-01-08 6:34 ` Vasily Kulikov
2013-01-08 4:02 ` Casey Schaufler
2013-01-08 4:02 ` Casey Schaufler
2013-01-08 6:38 ` Vasily Kulikov
2013-01-08 9:12 ` James Morris
2013-01-08 9:12 ` James Morris
2013-01-08 17:14 ` Casey Schaufler
2013-01-08 17:14 ` Casey Schaufler
2013-01-08 20:19 ` Kees Cook
2013-01-09 13:42 ` James Morris
2013-01-09 13:42 ` James Morris
2013-01-09 17:07 ` Casey Schaufler
2013-01-09 17:07 ` Casey Schaufler
2013-01-08 20:40 ` John Johansen [this message]
2013-01-09 13:28 ` James Morris
2013-01-09 13:28 ` James Morris
2013-01-10 10:25 ` John Johansen
2013-01-10 13:23 ` Tetsuo Handa
2013-01-11 0:46 ` Eric W. Biederman
2013-01-11 0:46 ` Eric W. Biederman
2013-01-11 0:57 ` John Johansen
2013-01-11 1:13 ` Eric W. Biederman
2013-01-11 1:13 ` Eric W. Biederman
2013-01-11 1:15 ` John Johansen
2013-01-11 18:13 ` Casey Schaufler
2013-01-11 18:13 ` Casey Schaufler
2013-01-11 19:35 ` Eric W. Biederman
2013-01-11 19:35 ` Eric W. Biederman
2013-01-08 17:47 ` Stephen Smalley
2013-01-08 17:47 ` Stephen Smalley
2013-01-08 18:17 ` Casey Schaufler
2013-01-08 18:17 ` Casey Schaufler
2013-01-08 20:01 ` John Johansen
2013-01-15 4:17 ` Casey Schaufler
2013-01-15 4:17 ` Casey Schaufler
2013-01-08 20:22 ` Kees Cook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50EC8447.1000301@canonical.com \
--to=john.johansen@canonical.com \
--cc=akpm@linux-foundation.org \
--cc=casey@schaufler-ca.com \
--cc=eparis@redhat.com \
--cc=jmorris@namei.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=selinux@tycho.nsa.gov \
--cc=sfr@canb.auug.org.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.