[OT] SELinux vs. other systems [was Re: [idea] udev + selinux]

[Linas Vepstas]

On Wed, Sep 01, 2004 at 10:29:34AM -0400, Colin Walters was heard to remark:
> [ The CC list here is rather nuts, someone needs to trim it...]
> 
> On Tue, 2004-08-31 at 17:44 -0500, Linas Vepstas wrote:
> 
> > Every now and then, I look at SELinux, and I get scared away by its
> > complexity.  
> 
> It is actually not that complicated, but if you're unfamiliar with
> mandatory access control (as I was when I first started learning about
> SELinux), it does require understanding some theory before you dive in.

Hmm, I thought I understood MAC; I was refering to the large numbers of
rules in SELinux.  Its not obvious (to me) that there isn't a path
through those rules that allows privledge escalation.  

For example: and correct me if I'm wrong, but its quite possible to 
write a complex rule set that intentionally leaves 'holes' allowing
for priveledge escalation.  Thus, by extrapolation, its quite possible
to write a set of rules that accidentally do the same.  When one is
presented with a set of rules, how does one know that they don't have a
hole? Answer: one audits the rules.  Unfortunately, there are a lot
of rules: last time I looked at one of the config files, it was
thousands of lines long.  Thus, a short, simple audit performed by
one person seems out of the question.  

Now, as to auditing...

> it's too complex?  I can certainly find plenty of examples of people not
> understanding Linux on linux-kernel; does that imply Linux is too
> complex?

We've had a fair number of "eyeballs" read the linux kernel, and thus
base our trust in its security on that.  However, the SELinux rules
are unlike the kernel in an important way: they are config files. 
This allows allows some anonymous fedora/debian/gentoo maintainer
to do something dumb like "gee, my USB camera doesn't work with udev,
but then when I change this selinux rule, it does", and poof, you've
lost the security.   I'm presuming that this kind of mucking around is 
far more common than altering lines of source in the kernel that weaken
security.   But I base my presumption on real life: go to any LUG,
hang out with any sysadmin long enough, and you will see them make
changes to config files that are dangerous if not outright incorrect.
Sysadmins are, as a species, people who work with incomplete knowledge
of the systems they administer.


> > Compare this to less complex security provided by e.g. the Linux 
> > VServer project.  

> VServer isn't solving the same problem as SELinux.  

Yes, that's right. I did try to point that out ... 

> That way, if e.g. the bind
> daemon running in one of the virtualized servers gets cracked, it
> doesn't mean a compromise of the whole virtual server.

No...  If the bind deamon gets cracked, it doesn't compromise the 'whole';
it only compromises root and anything else running in that context.  
It does not (in theory) compromise root in the other contexts.  In other 
words, one of the servers could be 0wned by someone truly hostile, 
while the 'whole' remains (theoretically) safe.

> Now, you can use a virtualization technology as a primitive form of
> separation by running e.g. your MTA in one virtual server, your name
> server in another, etc.  But that's rather painful, and is only an
> approximation to least privilege.

Yes, this is exactly what I'm thinking of.  But its not painful, 
it solves 90% or 100% of the needs of a 'typical' ISP/ASP/web server
admin.   Yes, this is indeed a blunt tool... see below:

> > Another example: Way back in the kernel-2.2 timeframe, I hacked on 
> > something neat: 'LOMAC': if you came in from a network connection, 
> > you lost permission to do almost anything, other than to e.g. webserve. 
> > The system was simple, worked well, the kernel patches were easy to audit, 
> > you could go home without worrying about priveledge escalation.  
> 
> That's also a rather blunt tool; SELinux is much more flexible.

What I'm proposing here is that bluntness can be traded for increased
assurances and increased ability to audit the code for "correctness". 
Yes, SELinux is far more flexible; but this is exactly what scares me.

I once thought about re-implementing LoMAC as a ruleset atop of SELinux.
I'm pretty sure that this is possible, but I started thinking that the
complexity of the ruleset may introduce holes that voids the effort.
And that thought disturbed me.

Along with Lomac's 'bluntness' comes 'zero configurability': its
something that could be installed on the proverbial 'Grandma's Linux
desktop', and provide additional security without causing pain.

With selinux, its not only not zero-conf, but its also not clear 
(to me) if the rulesets that install with debian/fedora/etc. actually
provide any additonal security at all against network breakins.
If the rulesets do indeed provide this protection, then there is a 
perception/marketing problem: people like me "don't get it" from
just skimming the selinux web pages.  I'd prefer to get all the 
benefits of SELinux without having to RTFM.


--linas