> 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