[CentOS] SELinux threads, cynicism, one-upmanship, etc.
lowen at pari.edu
Sat Nov 19 20:02:25 UTC 2005
> On Fri, 2005-11-18 at 21:29, Lamar Owen wrote:
>> What are the lessons a Linux admin can learn from
>> Windows malware scourges, some of which don't require you to be running
>> as an
> My take on it is that windows has crammed so much code and policy
> into the kernel and programs that must run as administrator that
> they will never be able to get all the bugs out. The lesson to
> learn - and the one that worked for unix the last 30 years - is to
> keep the kernel simple with simple, well understood mechanisms, and
> keep complex policy out of there.
If you look at the problem Windows NT and its children have is that it
must have compatibility with the simpler, but less secure, Windows 3.0
Enhanced Mode kernel (as Win95, 98, and ME are all based off this code,
which actually dates from late in the Windows 2.x 386 cycle). The problem
with Windows Malware is backwards compatibility to an old code base that
is not prepared for today's Internet. So much for older and simpler is
better; why don't we go back to VMS? It's substantially more secure than
Linux (the Linux kernel and heritage is not 30 years old, because Linux is
> And you reduce/eliminate those holes by keeping the code simple
> and well-understood.
So then let's get rid of the kernel code called netfilter. It will
simplifyy the kernel code and thus make it more secure. Right?
>> If there is no superuser in the
>> traditional sense, the root hole is useless. Completely useless.
> That's a separate issue, not really changed by adding more
> complexity in the kernel where the code can do anything.
Where can you do robust role-based access controls (and mandatory access
controls) but in the kernel? RBAC/MAC is not a service; it is not a
daemon; it really does need to run in the kernel, just like the netfilter
> But do you think the bugs can't be in the kernel itself?
Sure, bugs can be anywhere. They can be in the filesystem code. Or the
TCP/IP stack. Or virtually anywhere else in the kernel. But a bug in
SELinux will not result in a non-root user gaining root; SELinux only
restricts according to policy.
>> The only common advice used today that would have thwarted that exploit
>> running BIND chrooted.
> The mechanism was there all along, the policy wasn't - and the policy
> didn't belong in the kernel.
Sure, the policy of chroot is indeed in the kernel, and the kernel
enforces the chroot, no? Is chroot not a system call into the kernel?
Does it not restrict what the process can see and can do? Yes, it must be
configured; BIND or whatever daemon must be set up for a chroot. But the
kernel enforces the change in effective filesystem root; that is not a
The other typical answer to exploits is firewalling: pray tell where that
policy is enforced.
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
More information about the CentOS