> On Fri, 2005-11-18 at 21:29, Lamar Owen wrote:
>> What are the lessons a Linux admin can learn from
>> the
>> Windows malware scourges, some of which don't require you to be running
>> as an
>> administrator-equivalent?
> 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
not Unix).
> 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
code does.
> 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
>> was
>> 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
userspace function.
The other typical answer to exploits is firewalling: pray tell where that
policy is enforced.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu
