From: ebiederm@xmission.com (Eric W. Biederman)
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: "Serge E. Hallyn" <serge@hallyn.com>,
Kyle Moffett <mrmacman_g4@mac.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Bill Davidsen <davidsen@tmr.com>,
Stephen Smalley <sds@tycho.nsa.gov>,
James Morris <jmorris@namei.org>,
Andrew Morton <akpm@linux-foundation.org>,
casey@schaufler-ca.com, linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
Date: Wed, 10 Oct 2007 07:48:57 -0600 [thread overview]
Message-ID: <m1abqrt706.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20071008222058.208c6f32@the-village.bc.nu> (Alan Cox's message of "Mon, 8 Oct 2007 22:20:58 +0100")
Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
>> My very practical question: How do I run selinux in one container,
>> and SMACK in another?
>
> In the LSM model you don't because you could have the same container
> objects visible in different contains at the same time and subject to
> different LSMs. What does it mean to pass an SELinux protected object
> over an AppArmour protected unix domain socket into a SMACK protected
> container ?
You raise a good point. My intuitive definition would go something like
this. In the initial LSM space we would have whatever is the primary
LSM and it would always be invoked about everything. However it
would view a single container (no matter what user in that container)
as having a single set of permissions. Then the LSM in the container
be asked to further validate accesses, but it would distinguish
between users in the container.
At this point it looks like if I am going to be effective at doing
anything I am going to need to step back watch SMACK get merged and
then really look at what the LSM modules are implementing. Then
I can refactor the whole mess and move additional functionality into
the LSM to help me achieve other things.
> Really its the same problem as "I'd like to use different file permission
> systems on different process identifiers" and it would be very hard to
> get right simply because objects can pass between two different security
> models.
Yep. Although the isolation of a container with a completely
different set of namespaces is tight enough that except for people
debugging a container from processes in the container from outside the
container object exchange essentially doesn't happen.
You do raise a very good question here. Does an LSM implement a
different file permission system? Or does an LSM implement a firewall
between processes?
Certainly selinux seems too programmable to be considered just a
different file permission system.
> Pyramid tried to do the "simple" case of BSD and System 5 on the same box
> and got caught out even with that because of the different rules on stuff
> like chgrp..
Yes. There are many hard problems here and many people have tried and
failed in the past. That hasn't stopped me before, and I don't see
why security should be any different.
Eric
next prev parent reply other threads:[~2007-10-10 13:52 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-30 0:20 [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel Casey Schaufler
2007-09-30 8:16 ` Andrew Morton
2007-09-30 8:42 ` Andi Kleen
2007-09-30 17:14 ` Casey Schaufler
2007-09-30 17:34 ` Andi Kleen
2007-09-30 23:24 ` david
2007-09-30 17:29 ` Joshua Brindle
2007-09-30 17:39 ` Andi Kleen
2007-09-30 19:07 ` Theodore Tso
2007-09-30 20:05 ` Andi Kleen
2007-09-30 20:22 ` Theodore Tso
2007-10-01 20:28 ` Casey Schaufler
2007-09-30 20:18 ` Paul Moore
2007-09-30 9:53 ` Christoph Hellwig
2007-09-30 17:19 ` Casey Schaufler
2007-10-02 8:36 ` Thomas Bleher
2007-09-30 17:02 ` Casey Schaufler
2007-09-30 20:30 ` Paul Moore
2007-10-01 11:33 ` James Morris
2007-10-01 15:07 ` Linus Torvalds
2007-10-01 15:40 ` Stephen Smalley
2007-10-01 16:04 ` Linus Torvalds
2007-10-01 17:54 ` Olivier Galibert
2007-10-02 21:02 ` Bill Davidsen
2007-10-02 21:20 ` Linus Torvalds
2007-10-02 23:25 ` Linus Torvalds
2007-10-03 0:12 ` Alan Cox
2007-10-04 22:56 ` Derek Fawcus
2007-10-04 23:18 ` Chuck Ebbert
2007-10-04 23:44 ` Derek Fawcus
2007-10-03 5:32 ` Crispin Cowan
2007-10-03 3:54 ` Bill Davidsen
2007-10-03 4:52 ` Linus Torvalds
2007-10-05 1:44 ` Eric W. Biederman
2007-10-05 3:04 ` Kyle Moffett
2007-10-05 4:45 ` Eric W. Biederman
2007-10-05 5:48 ` Kyle Moffett
2007-10-05 16:27 ` Casey Schaufler
2007-10-05 18:42 ` Stephen Smalley
2007-10-05 20:08 ` Casey Schaufler
2007-10-05 20:11 ` Eric W. Biederman
2007-10-08 17:50 ` Casey Schaufler
2007-10-08 18:47 ` Eric W. Biederman
2007-10-08 18:53 ` Serge E. Hallyn
2007-10-08 21:05 ` Casey Schaufler
2007-10-08 16:18 ` Serge E. Hallyn
2007-10-08 17:31 ` Casey Schaufler
2007-10-09 13:52 ` Stephen Smalley
2007-10-09 16:02 ` Casey Schaufler
2007-10-08 23:24 ` Bill Davidsen
2007-10-08 16:06 ` Serge E. Hallyn
2007-10-08 17:20 ` Eric W. Biederman
2007-10-08 18:00 ` Serge E. Hallyn
2007-10-08 19:29 ` Eric W. Biederman
2007-10-08 19:50 ` Eric W. Biederman
2007-10-08 20:39 ` Casey Schaufler
2007-10-08 21:02 ` Eric W. Biederman
2007-10-08 21:20 ` Alan Cox
2007-10-10 13:48 ` Eric W. Biederman [this message]
2007-10-10 15:45 ` Stephen Smalley
2007-10-10 17:57 ` Casey Schaufler
2007-10-11 10:46 ` Kyle Moffett
2007-10-11 15:41 ` Casey Schaufler
2007-10-11 18:53 ` Kyle Moffett
2007-10-11 20:09 ` Alan Cox
2007-10-08 21:51 ` Crispin Cowan
2007-10-30 4:01 ` Kazuki Omo(Company)
2007-10-30 15:07 ` Casey Schaufler
2007-10-08 20:25 ` Casey Schaufler
2007-10-08 20:57 ` Eric W. Biederman
2007-10-06 19:14 ` Bill Davidsen
2007-10-03 0:10 ` Alan Cox
2007-10-03 0:18 ` Linus Torvalds
2007-10-01 16:39 ` Casey Schaufler
2007-10-01 19:00 ` Theodore Tso
2007-10-01 15:38 ` Casey Schaufler
2007-10-01 20:49 ` Jan Engelhardt
2007-10-01 3:47 ` Serge E. Hallyn
2007-10-01 4:15 ` Casey Schaufler
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=m1abqrt706.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=casey@schaufler-ca.com \
--cc=davidsen@tmr.com \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mrmacman_g4@mac.com \
--cc=sds@tycho.nsa.gov \
--cc=serge@hallyn.com \
--cc=torvalds@linux-foundation.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox