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?

Eh? How can they get away with selling that?

[SumDeusExMachina]

First of all, I'd like to know what the hell they were thinking when they did this? I mean, it's a glorified chroot jail, and we all know what a breeze those are to administrate (like compiling a seperate set of libs for each app that runs in one). Really, one could do this for free either by using FreeBSD's superior security features or just going with the NSA's linux distro.

Secondly, I'd like to know exactly how they can get away with this and not violate the GPL? They are clearly writing software that interacts with the components of a GPL'ed piece of software (the Linix kernel), and according to the GPL, that means that their extensions ought to be under the GPL as well. So where are the source code downloads, HP? Hmmm? Maybe you'll be getting a letter from the FSF's legal team sometime soon.

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

NSA selinux

[jlkinsel]

I've been developing some firewall products and distributed IDS nodes based around NSA's secure linux kernel and tools. Takes some time to get used to, but the marketability plus just starting with a base that's been *really* hardened is a pretty nice combo on an already good thing. John

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.

Security concerns with HP-LX

[JonathanF]

I've heard at least one or two people here worry about HP's security in HP-LX (and HP-UX) and I have to say this: anyone who depends on their OS as the primary basis of security - at least in this day and age - is not properly looking at security in the first place.

If you are (or were) a network admin, would you host an Internet server without a firewall just because you used one OS and not another? I don't think so. Total security involves additional layers on top of the OS - firewalls, requiring passwords for many or all access points, and so on - as well as an admin that keeps up to date on security holes and works to plug them.

That's not to excuse OS developers who leave their products ripe for abuse, but so long as reasonable steps are taken as part of the OS I wouldn't be slandering its maker - that is, unless they're promising something they know they can't deliver.

RSBAC & *plug*

[21mhz]

RSBAC is Secure Linux Done Proper (or almost there).
Castle from ALT Linux Team is a Linux distribution that uses RSBAC and chroot jails. Also, recently, the tcb scheme has been adopted for secure access to system passwords without need for setuid root.

Name collision with HP LX Palmtop series

[denmon]

HP-LX is an unfortunate shorthand name for this product, since "HP-LX" is a widely used to refer to HP's excellent (but discontinued) line of DOS based palmtops - HP 95LX, HP100LX, and HP200LX. It appears from the technical brief PDF that the official name is "HP Secure OS for Linux". Perhaps some other name could be used to avoid confusion, like "HP-SLX" (secure Linux).

For more information on the LX palmtops, see the FAQ at http://www.hplx.net/faq.faq.html. Attached below is a short excerpt from the FAQ that provides some background.

---

Q. What is the HP100LX?
Depending on your point of view, it's either an IBM PC-XT stuffed into a very tiny case with some Personal Information Management (PIM) software and Lotus 1-2-3 built into ROM, or it's a high-end electronic organizer that also runs MS-DOS software.

Q. What is the HP200LX?
It's the successor to the 100LX. It's essentially a 100LX with cosmetic changes and the addition of Pocket Quicken, LapLink Remote, and some feature enhancements for the PIM applications in the ROM.

Q. What is the HP Omnigo 700LX?
It's basically a somewhat faster 200LX with a docking cradle for a Nokia GSM cellular phone, some LEDs on the front, and some extra built-in communications software. It is only available in Europe and Asia/Pacific, where the GSM standard is, well, standardized. This product has been discontinued by HP and is no longer sold. If you can get a used one, it's possible to use it in the US if you live in an area where GSM coverage is offered (i.e. California, Nevada, etc.) if you get a compatible phone. The Nokia 2190 fits the OmniGo 700LX's cradle and works in the US, for example.

Q. Why would I want an outdated DOS palmtop when I could get a modern Windows CE machine?
The 200LX may be a few years old, but it is a far better computing device than any Windows CE machine. A few of its strengths:
- Battery life (up to 2 months on a single pair of batteries)

- DOS compatibility (can run millions of programs written for desktop computers)

- High-resolution screen (fully CGA compatible, 640x200 [33% wider than most WinCE units])

- Better keyboard (separate numeric keypad; nice solid feel with good tactile feedback)

- Better PIM apps (built-in apps are unsurpassed for quality and ease of use)

- Pocket Quicken built in (keep track of your finances without spending any extra money for the financial software)

- Better expansion support (see flash cards and other memory expansions as a drive, not just a folder)

Q. Why would I want an outdated DOS palmtop when I can get a sleek PalmPilot or Palm III?
The PalmPilot series is made for a completely different purpose than the 200LX. The 200LX is essentially a full-blown computer that fits in your pocket, and doubles as an organizer. The PalmPilot series are meant to be organizers and to help connect with desktop computers. Both platforms have their strengths and weaknesses, but for real computing in the palm of your hand, the 200LX is the only choice.
---

Why yet another CWM/B1 effort?

[Roxy]

In my opinion (as a practicing Head of Information Security and a former Security Architect for a number of kernels) what Linux really needs are capabilities (which we have, we just need to start using them by default) and a functioning audit subsystem. A functioning audit subsystem does not compromise only the kernel part, but also the audit compression/reduction facilities (normally done in user space) and the tools to define what events to audit and tools to search and securely store audit trails.

Audit trails that can be (semi-) trusted is what most of us security people demand, and which Linux doesn't deliver (don't tell me about syslog, as it is designed for IT administrators, not security administrators).

These seems to be present in the HP-LX (can't access HP's website right now, but I assume it is based on the old SecureWare code HP purchased a while back and been using the last couple of years). Unfortunately, what Bruce (Perens) says about that it would be easy to reconstruct the user space parts of the auditing subsystem I disagree with, as this is the majority of the code and also the most complex part.

With Best Regards

Roland B.

The mythical idiot-proof distro/OS

[Deus Ex Machina]

Call me on this if I am wrong here, but is the major factor in spending $3000 on this gem of software is chroot jails (or a reasonable facimile)? The article was rather brief, but from the look of it, aside from that feature - which the article even admits is not new - we have one other feature, that it is "secure by default". Well, does it keep you from installing Telnet ever? What about the Berkeley R-tools? The SSH root admin thing looks clever at first, but how many places have you worked at where the same root password was used across multiple boxen - even those of different OSs? Now, how much do you want to bet that the password over the SSH key is going to be the same, or similar, to the password for root itself in most installations? How is this any different than simply having a second login prompt for root?

Look, I'm sure someone else has said this already a million times here, and I know Bruce Schneier makes it his mantra, but I'll repeat it for those of us who came late: Most of security has nothing to do with software, and everything to do with poor procedure. All the chroot jails in the world cannot restrain the sheer magnitude of people's apathy toward secure practice and process.

And yes, sometimes even the best security is broken. Let's face it, if you want your data secure, you are already outnumbered millions to one. Yet, this is a default condition - the majority of security vulnerabilites are relative to the actions of script kiddies, who use network flooding and other lame attacks to force people off the net and crash systems. Adding another security layer will make it harder to brute-force your way in, certainly, but what's the point of sealing the door with concrete if lazy administration practice leaves the windows wide open?

And, how does this differ from OpenBSD? I'm not a BSD zealot, but way too much of this sounds like the exact practice taken toward OpenBSD development. Does this software deserve extra creds because it costs more? Are people more likely to take security seriously if they spend $3000 on an operating system than if they get it for free? How much of this code is audited? All the default packages? Did they audit anything, or did they just implement chroot jails and assume they have found a "workaround" for a malignent problem in UNIX security?

I'm not saying that this is a bad idea. I'm sure this distro will provide for a more secure environment by default, for those of us who don't have the time to audit our production boxes. But I just don't see reason to presume that this distro is any more secure than a properly configured SELinux or OpenBSD box. And please, if you think I'm wrong, enlighten me, because I'm no expert. I just think that building a better mouse trap is pointless when the trap operators don't know how to operate it.