HP-LX 1.0 Secure Linux

kengreenebaum writes: "Webtechniques has a short but interesting article on HP's approach to a secure but expensive LINUX distro. Basically they started with RedHat 7.1 and added compartments; an extension to the age-old chroot jail concept where the processes representing major services run. Kernel extensions allow HP (or the administrator) to specify which compartments can access which kernel resources including individual files, network stacks, and each other. HP has Technical Product Brief as well as other material online. Interesting to compare HP's approach to that of the NSA's Secure Linux projects. These concepts sound like a solid way to prevent buffer overflow type security holes in individual services from compromising the entire machine. At $3000 HP-LX is too expensive for many to experiment with but the NSA's code seems to be more readily available. Anybody have experience with these distributions or with similar approaches to Linux security?"

Comments

There are major problems with compartmentalization

[va_willy]

Having worked on a similar project in the past, I can tell you that UNIX kernels are not as amenable to compartmentalization as HP would have you believe. Consider the following potential holes:

• Buffer overflows and improper argument checking plague every modern UNIX kernel. Think about the recent sysctl() input validation hole in Linux. Or the recent /proc bugs in FreeBSD. Or the LDT handling bugs in NetBSD, Solaris, and many others.
• Most kernels were not designed with least privilege in mind. For instance, the mount() syscall allows ordinary users to mount and umount filesystems. Access checks are performed (to make sure it is mounted nosuid, and such) but there are undoubtedly holes waiting to be discovered.
• Until only recently, Linux had several bugs allowing users to commandeer each others' shared memory segments. This could be used to corrupt memory used by init(1) and several other critical programs, causing a major security breach.
• Because the X server needs low level hardware access, most OS kernels allow access to iopl(2) and ioperm(2). This means that attackers can talk directly with the hardware, bypassing the OS security. The alternative, of course, is to ban the use of graphical interfaces on that system; but usually that is unacceptable.

Although these issues can all be addressed, the problem of proper kernel security is at best a "whack a mole" situation in which a new hole will arise shortly after an existing hole is patched. Thus, the HP-LX software probably isn't worth the CD it is pressed onto.

vw