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