linux-kernel - Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m1ir5liaoh.fsf@ebiederm.dsl.xmission.com>
Date:	Fri, 05 Oct 2007 14:11:26 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Stephen Smalley <sds@...ho.nsa.gov>
Cc:	casey@...aufler-ca.com, Kyle Moffett <mrmacman_g4@....com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Bill Davidsen <davidsen@....com>,
	James Morris <jmorris@...ei.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org, "Serge E. Hallyn" <serge@...lyn.com>
Subject: Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

Stephen Smalley <sds@...ho.nsa.gov> writes:

> On Fri, 2007-10-05 at 09:27 -0700, Casey Schaufler wrote:
>> --- Kyle Moffett <mrmacman_g4@....com> wrote:
>> 
>> > On Oct 05, 2007, at 00:45:17, Eric W. Biederman wrote:
>> > > Kyle Moffett <mrmacman_g4@....com> writes:
>> > >
>> > >> On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote:

>> > > Yes. Currently with containers we are taking that one step farther  
>> > > as that solves a wider set of problems.

>> > So containers are exclusive subsets of "the system" while LSM should  
>> > be about non-exclusive information restriction.
>> 
>> Yes. Isolation is a much simpler problem than access control.

Yes.  Simple isolation is a different and simpler problem that can be
solved with the LSM hooks today.  I brought it up for the contrast in
what the LSM hooks can be useful for.  Hopefully allowing the LSM
hooks to be perceived as something other then just hacks for selinux.

Using a security module for isolation is currently uninteresting
because it would preclude use of a security module like selinux or
smack, because we can have at most one security module at a time
loaded.

I have seen several other places where a custom LSM would have
been a good solution but because we don't allow composition solving
a little problem with the LSm is not interesting enough to allow
the code to be merged.

So I see the current structure of the LSM hooks as hindering
development.

>> > >
>> > > I think it is firmly established that selling SElinux to everyone  
>> > > is politically untenable.  However enhancing the LSM (even if it is  
>> > > mostly selinux code movement down a layer) I think can be sold.
>> 
>> That would be silly. Smack uses a significantly smaller set of hooks
>> than SELinux requires and still does interesting things. We went through
>> the "replace LSM with the SELinux interface" exercise a couple years
>> ago, I would hate to have to regurgitate all those discussions.
>
> I don't think Eric is proposing replacing LSM with the SELinux interface
> as it exists today, but rather making LSM more Netfilter-like and
> radically refactoring SELinux (and any other security module) to consist
> of a chain of smaller modules that are more general and reusable, and
> that can be composed and applied in interesting ways via an
> iptables-like interface.  I'm not sure what that would look like
> exactly, but it seems reasonable to explore.

Exactly refactoring security modules into small simple reusable chunks
to allow reuse.  It might look something like selinux chains or it
might not.  Inherently it needs to expose what you can do at the
existing hook points, and it needs to allow usage by different modules
that are compiled in at the same time.

It is certainly the case that you would not need to use all of the
existing hooks to get something done.

> One of the things left unresolved with LSM is userland API, and it does
> involve more than just returning EPERM or EACCES to applications.  You
> already have patched ls and sshd programs, and have acknowledged the
> need for more userland modifications to ultimately achieve your own
> goals.  If LSM is going to succeed in the kernel, then ultimately you
> need some common API for userland so that you don't need separate
> versions of ls, ps, sshd, etc for Smack vs SELinux vs. whatever.

Likely.  Until we have a generalized LSM interface with 1000 config
options like netfilter I don't expect we will have grounds to talk
or agree to a common user space interface.  Although I could be
wrong.

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