Quoting Casey Schaufler (casey@schaufler-ca.com):
quoted text
> 
> --- Kyle Moffett <mrmacman_g4@mac.com> wrote:
> 
> > On Oct 05, 2007, at 00:45:17, Eric W. Biederman wrote:
> > > Kyle Moffett <mrmacman_g4@mac.com> writes:
> > >
> > >> On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote:
> > >>> SElinux is not all encompassing or it is generally  
> > >>> incomprehensible I don't know which.  Or someone long ago would  
> > >>> have said a better  way to implement containers was with a  
> > >>> selinux ruleset, here is a  selinux ruleset that does that.   
> > >>> Although it is completely possible  to implement all of the  
> > >>> isolation with the existing LSM hooks as  Serge showed.
> > >>
> > >> The difference between SELinux and containers is that SELinux (and  
> > >> LSM as a whole) returns -EPERM to operations outside the scope of  
> > >> the  subject, whereas containers return -ENOENT (because it's not  
> > >> even in  the same namespace).
> > >
> > > Yes.  However if you look at what the first implementations were.   
> > > Especially something like linux-vserver.  All they provided was  
> > > isolation.  So perhaps you would not see every process ps but they  
> > > all had unique pid values.
> > >
> > > I'm pretty certain Serge at least prototyped a simplified version  
> > > of that using the LSM hooks.  Is there something I'm not remember  
> > > in those hooks that allows hiding of information like processes?
> > >
> > > Yes. Currently with containers we are taking that one step farther  
> > > as that solves a wider set of problems.
> > 
> > IMHO, containers have a subtly different purpose from LSM even though  
> > both are about information hiding.  Basically a container is  
> > information hiding primarily for administrative reasons; either as a  
> > convenience to help prevent errors or as a way of describing  
> > administrative boundaries.  For example, even in an environment where  
> > all sysadmins are trusted employees, a few head-honcho sysadmins  
> > would get root container access, and all others would get access to  
> > specific containers as a way of preventing "oops" errors.  Basically  
> > a container is about "full access inside this box and no access  
> > outside".
> > 
> > By contrast, LSM is more strictly about providing *limited* access to  
> > resources.  For an accounting business all client records would  
> > grouped and associated together, however those which have passed this  
> > year's review are read-only except by specific staff and others may  
> > have information restricted to some subset of the employees.
> >
> > 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.
> 
> > >>> We also have in the kernel another parallel security mechanism  
> > >>> (for what is generally a different class of operations) that has  
> > >>> been  quite successful, and different groups get along quite  
> > >>> well, and  ordinary mortals can understand it.   The linux  
> > >>> firewalling code.
> > >>
> > >> Well, I wouldn't go so far as the "ordinary mortals can understand  
> > >> it" part; it's still pretty high on the obtuse-o-meter.
> > >
> > > True.  Probably a more accurate statement is:`unix command line  
> > > power users can and do handle it after reading the docs.  That's  
> > > not quite ordinary mortals but it feels like it some days.  It  
> > > might all be perception...
> > 
> > I have seen more *wrong* iptables firewalls than I've seen correct  
> > ones.  Securing TCP/IP traffic properly requires either a lot of  
> > training/experience or a good out-of-the-box system like Shorewall  
> > which structures the necessary restrictions for you based on an  
> > abstract description of the desired functionality.  For instance what  
> > percentage of admins do you think could correctly set up their  
> > netfilter firewalls to log christmas-tree packets, smurfs, etc  
> > without the help of some external tool?  Hell, I don't trust myself  
> > to reliably do it without a lot of reading of docs and testing, and  
> > I've been doing netfilter firewalls for a while.
> > 
> > The bottom line is that with iptables it is *CRITICAL* to have a good  
> > set of interface tools to take the users' "My system is set up  
> > like..." description in some form and turn it into the necessary set  
> > of efficient security rules.  The *exact* same issue applies to  
> > SELinux, with 2 major additional problems:
> > 
> > 1)  Half the tools are still somewhat beta-ish and under heavy  
> > development.  Furthermore the semi-official reference policy is  
> > nowhere near comprehensive and pretty ugly to read (go back to the  
> > point about the tools being beta-ish).
> > 
> > 2)  If you break your system description or translation tools then  
> > instead of just your network dying your entire *system* dies.
> > 
> > 
> > >>> The linux firewalling codes has hooks all throughout the  
> > >>> networking stack, just like the LSM has hooks all throughout the  
> > >>> rest of linux  kernel.  There is a difference however.  The linux  
> > >>> firewalling code in addition to hooks has tables behind those  
> > >>> hooks that it  consults. There is generic code to walk those  
> > >>> tables and consult with different kernel modules to decide if we  
> > >>> should drop a packet.  Each of those kernel modules provides a  
> > >>> different capability that can be used to generate a firewall.
> > >>
> > >> This is almost *EXACTLY* what SELinux provides as an LSM module.   
> > >> The one difference is that with SELinux some compromises and  
> > >> restrictions  have been made so that (theoretically) the resulting  
> > >> policy can be  exhaustively analyzed to *prove* what it allows and  
> > >> disallows.  It  may be that SELinux should be split into 2 parts,  
> > >> one that provides  the underlying table-matching and the other  
> > >> that uses it to provide  the provability guarantees.  Here's a   
> > >> direct comparison:
> > >>
> > >> netfilter:
> > >>   (A) Each packet has src, dst, port, etc that can be matched
> > >>   (B) Table of rules applied sequentially (MATCH => ACTION)
> > >>   (C) Rules may alter the properties of packets as they are routed/
> > >> bridged/etc
> > >>
> > >> selinux:
> > >>   (A) Each object has user, role, and type that can be matched
> > >>   (B) Table of rules searched by object parameters (MATCH => allow/
> > >> auditallow/transition)
> > >>   (C) Rules may alter the properties of objects through transition  
> > >> rules.
> > >
> > > Ok.  There is something here.
> > >
> > > However in a generic setup, at least role would be an extended  
> > > match criteria provided by the selinux module.  It would not be a  
> > > core attribute.  It would need to depend on some extra  
> > > functionality being compiled in.
> > 
> > Now see I think *THAT* is where Casey should be going with his SMACK  
> > code.  Don't add another LSM, start looking at SELinux and figuring  
> > out what parts he does not need and how they can be parameterized out  
> > at build time for smaller systems.
> 
> Good suggestion. In fact, that is exactly how I approached my
> first two attempts at the problem. What you get if you take that
> route is an imposing infrastructure that has virually nothing
> to do and that adds no value to the solution. Programming to the
> LSM interface, on the other hand, allowed me to drastically reduce
> the size and complexity of the implementation.

(tongue-in-cheek)

No no, everyone knows you don't build simpler things on top of more
complicated ones, you go the other way around.  So what he was
suggesting was that selinux be re-written on top of smack.

:)

-serge
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/