not installing SELinux with Fedora

[Steve G]

Hi,

>Steve, take a look at "sHype: Secure Hypervisor
>Approach to Trusted Virtualized Systems" an IBM

OK. If you are running Xen, there may need to be some adjustments. I haven't
taken a deep look at that yet. 

>"Mandatory access control has been designed and
>implemented for the Linux operating system (cf. SELinux
>[1]). However, controlling access of processes to
>kernel data structures has led to an extremely complex
>security policy.

I don't think this is correct. SE Linux doesn't control access per se to kernel
structures. The enforcement is between user space entities. I would agree that
some work can be done to better visualize what the policy is doing. As soon as I
wrap up work on the audit system, I want to look into this.

>Therefore, SELinux does not enforce
>strong isolation properties equivalent to those offered
>when running applications on separate hardware
>platforms.

This is true. One machine cannot really corrupt another machine. But I find it to
be flawed logic to say that because the author thinks policy is complex, it
doesn't offer the same protection as having 2 distinct machines. Its flawed
thinking.

>Operating system security controls such as
>those offered by SELinux are more appropriate for
>enforcing mandatory access control among a set of
>closely cooperating applications, which naturally share
>a hardware platform.

This wording suggests the author has an alterior motive. SE Linux is good for
controling the flow of information at the OS level. Any virtualization scheme is
going to have similar needs. In a hypervisor system, most information flow will
be via tcp/ip. An exploit in one level may allow the breach of another level. But
because you don't have a policy across the virtualization levels, you have no way
of making centralized decisions. There is protection offered in that corruption
of one image doesn't immediately affect the others. But there are blind spots,
too.

>The point is that SELinux is: (1) so complex as to be
>unmanageable; (2) inappropriate for all cases,

I'll agree with the fact that its not needed in all cases. However, if you have a
machine with exposure to hostile traffic, you are better off with it than
without. If you are in a protected lab with no chance of rogue processes and
pushing the machine to its limit, I'd say you really don't need it.

>On a more general note Steve, take a look at Ken
>Thompson's 1984 ACM Turing Award lecture, "Reflections
>on Trusting Trust" wherein the author of the UNIX
>operating system illustrates why you shouldn't trust
>sneaky folks like him.

Sure, all this open source software could have hidden holes in it. Your best
protection in this case is to stay with the herd and hope someone spots the hole
before anyone gets hacked. The more eyes looking, the better chances of problems
getting fixed.

> By extension, I'm a little
>suspicious of the NSA's motives in distributing a
>system for mandatory access control that is needlessly
>complex and, essentially, unmanageable 

I think you are missing one major element. People not associated with NSA are
peer reviewing it. There's a lot more people involved in it. To say all the
contributions came from the NSA is misleading.

>at a time when snort

Snort is crap. I code reviewed it and argued with the developers and they just
didn't get it. ACID is crap. Everything related to snort is crap. Besides, this
isn't protection. By the time snort says you are being attacked, it might be
over. You'll spend a day reinstalling the machine. I put my review of snort on
their mail list. There's so much code, I think I broke it up into 5-6 smaller
reviews.

>and tripwire, for example, are widely available

But if someone compromises the machine, you can't trust tripwire anymore. Again,
its only capable of telling you something happened, not protecting you against
exploit.

>and a stateful firewall is built into the Linux kernel.

Right. IPtables is good.

>Chris and Steve, you're abolutely correct. Fedora is
>the only widely used Linux distribution to incorporate
>SELinux in such a manner that it cannot be removed.

No. I removed it once. Its very easy to do, but you will be running your own
distro. :)  Just get a RH9 build host and use the rookery build system. It'll let
you know which packages need TLC.

>If its so important, how come everybody else can get along
>without it? 

Well, they are using DAC and hoping that code reviews have caught all the
problems. SE Linux is an evolution in thinking. Suppose there are holes in the
apps that we don't know about and bad guys do. How do you even begin to protect a
system? The only symptom that you have is that suddenly bind want to run a shell.
How do you spot variances like that? This is what SE Linux was designed to stop.

>Perhaps we might consider an alternative
>Fedora Core 4 distro that is free of this one-stop
>security panacea?

All you have to do is turn it off. If you can spot security hole in that
configuration that is not DAC related...a whole lot of people will want to know.
SE Linux does need some help in managing policy. I see it kind of like when IP
Tables was introduced. At first you have to code rules by hand. Then later apps
like firewall builder came along and you could drop and drag firewall rules. This
is what's missing from SE Linux. A good configuration for the non-security
expert.

I cannot possibly convince you to use it. Nor will I try. I think each
installation may be unique in its needs. You are right in questioning it as it
may not fit what you are doing. But if you compile your own distro, you will be
moving away from the herd and possibly susceptible to attacks that everyone else
survives.

-Steve


		
____________________________________________________ 
Yahoo! Sports 
Rekindle the Rivalries. Sign up for Fantasy Football 
http://football.fantasysports.yahoo.com