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

NSA SELinux

[joshamania]

I'd just like to comment upon the NSA's Security-Enhanced Linux project.

It is certainly more accessible, and I've prompted my company to look into it. Considering the current political environment, I believe this is a good way for small consulting companies to distinguish themselves.

"Why, yes, Mr. Customer, we are very familiar with computer security and specialize in using products developed by the National Security Agency. If it's good enough for the NSA, don't you think it is good enough for your business?

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

HP was committed to Debian...

[leandrod]

...whatever happened to that commitment? I mean, were there any technical or (and) historical reasons for choosing Red Hat, or is that yet another instance of choice by misinformation or herd instinct?

As I have said before...

[farrellj]

HP is dumping HP-UX, and will be moving people to Linux...no one ever listens...

ttyl
Farrell

I'm not sure it helps enough

[markj02]

Purely as an engineering tradeoff, I'm not sure that this helps very much. While this may slow down a determined attacker, this kind of approach tends to fall like a series of domnios: the first one gets compromised giving the attacker a few more capabilities, then the next one, etc. The Linux kernel was simply not designed with ensuring this kind of isolation.

As a practical matter, it may help a lot because it makes the machine different from other Linux machines. It may be not too hard conceptually to work out how to break through this kind of security, it will likely protect systems from common exploits of common bugs.

However, in the long term, the only solution I see to security problems is to build on foundations that have support for guarding against common bugs and analyzing security-related program properties. That means, among other things, using languages with built-in default checks for buffer overruns and using languages with type systems that can be used to verify that data doesn't get where it isn't supposed to get (Perl's notion of "tainted" is a simple runtime example; similar static type checking is also possible in some cases). Decades of UNIX, Windows, and Linux software development and bug tracking have shown that without such support, even skilled programmers simply cannot write software containing very serious security problems in actual releases. In different words, the Linux and Windows kernels and daemons will have to be rewritten in something other than C or C++. Sorry.