User: Password:
|
|
Subscribe / Log in / New account

Re: LSM stacking/secondary modules / RFC: Socket MAC LSM

From:  Casey Schaufler <casey-AT-schaufler-ca.com>
To:  Paul Moore <paul.moore-AT-hp.com>
Subject:  Re: LSM stacking/secondary modules / RFC: Socket MAC LSM
Date:  Sun, 18 Jan 2009 15:19:14 -0800
Message-ID:  <4973B8F2.7080205@schaufler-ca.com>
Cc:  Stephan Peijnik <stephan-AT-peijnik.at>, Greg KH <greg-AT-kroah.com>, Rafael Konrath <rafael.konrath-AT-gmail.com>, linux-security-module-AT-vger.kernel.org
Archive-link:  Article

Paul Moore wrote:
> As discussed previously on this list (mostly in relation to filesystem 
> issues but it turns out the socket/network issues are very similar) 
> while it seems like a reasonable approach at a high level I think you 
> will find that once you get down to the lower levels it becomes very 
> difficult to adopt a general purpose solution that allows stacking.

SELinux and Smack should never be stacked in the same kernel.
AppArmor or TOMOYO and Smack you could make an argument for
stacking in the same kernel. AppArmor and an LSM that does
just UID based network access controls* would probably be a
very good fit.

Stacking of special purpose LSMs would be a great idea.
One reason that we don't have special purpose LSMs is that
you can't stack them, you have to provide the entire "solution"
in the one LSM. Of course, complete solutions don't stack.

I would be very interested to see an LSM that does nothing
but multiplex other LSMs. That would make multiple unrelated
LSMs feasible without trying to create something that could
deal with SELinux's and Smack's different notions of network
access control model. You could revive the notion of loadable
modules while you're at it. The LSM Multiplexer LSM could put
any restrictions on the LSMs it is willing to support.

>   
> The most obvious problem is the issue of state specific to each 
> security module and how to ensure that the state is managed in such a 
> way that it is always correct regardless of what happens at the 
> different stacked layers.  With networking the issue would be 
> per-socket labels and other meta-data; check out SELinux's 
> sk_security_struct to get an idea of some of the state that needs to be 
> maintained for each socket.
>
> Granted, I think it might be possible to a specific stacking solution 
> for two specific security modules but it would require a lot of special 
> handling specific to the two modules and wouldn't likely extrapolate to 
> a general purpose solution in any way that would make sense.
>
>   

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



(Log in to post comments)


Copyright © 2009, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds