Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Linux Software

HP-LX 1.0 Secure Linux 182

Posted by michael from the thirty-percent-fewer-rootkits dept.
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?"
This discussion has been archived. No new comments can be posted.

HP-LX 1.0 Secure Linux More

HP-LX 1.0 Secure Linux

Comments Filter:

  • NSA SELinux (Score:4, Interesting)

    by joshamania ( 32599 ) <jggramlich@NosPam.yahoo.com> on Saturday December 29, 2001 @02:07PM (#2762844) Homepage
    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?
    • 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?

      Somewhat like Magic Lantern? Or was that some other USGov organization?

      I'm not so sure I want to trust "government-level" security these days...
      • The difference is its a set of kernel patches. You can read them and see if there is anything improper going on..
  • Doesn't HP have to release their source code to comply with the GPL?

    • Re:What about GPL, GNU, etc? (Score:5, Insightful)

      by pmcneill ( 146350 ) on Saturday December 29, 2001 @02:13PM (#2762868)
      Yes and no. They have to release the source to the people to whom the product is distributed. However, they don't have to make it publically available. The catch is that the people who receive the source can also redistribute it at will. As someone else pointed out, the source is available here [hp.com].

      I expect, however, that HP has some proprietary stuff that's included in non-GPLd binaries.
    • While this is a good question, (gpl, gnu) I don't believe it should be the first question raised about contributions to the GNU/Linux code base. Just my own HO, but a thanks to HP for coming to the party .

      Grteg
    • The kernel modifications are released under GPL but the administration tools are traditional closed source, which complies with the GPL. Anyone is free to write their own administration tools if the wish. Many large companies would prefer the support of HP rather than "rolling their own".
      • The last time we bought an HP 9000 at work, the sales people said that it could run Linux instead of HP-UX if we wanted. But this article doesn't mention PA-RISC at all. Does anyone know if these high-security features of HP-LX are already in the PA-RISC version of linux?

  • NSA Linux distribution (Score:5, Funny)

    by Anonymous Coward on Saturday December 29, 2001 @02:09PM (#2762853)
    I installed their distribution and it works fine, except for the GUI login which says "Welcome to wiretap029114.nsa.gov". How do I change it back to "localhost.localdomain"?

  • Get your source code... (Score:5, Informative)

    by TrumpetPower! ( 190615 ) <ben@trumpetpower.com> on Saturday December 29, 2001 @02:10PM (#2762862) Homepage

    ...here [hp.com].

    b&

  • In the article they mentioned programs use authentication based on ssh private keys. This is all fine and dandy, but what about doing this for $0 rather then $3000 and just kerberizing your own apps. Then you can have total control over more than just some of the admin functions, plus you start off with a nice base for more infrastructure later.
  • 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 (Score:5, Interesting)

    by va_willy ( 546726 ) on Saturday December 29, 2001 @02:14PM (#2762874) Homepage
    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

    • The alternative, of course, is to ban the use of graphical interfaces on that system; but usually that is unacceptable.
      On a server? I never install X, too many performance and security trade offs.
    • These are very valid concerns. However, it seems to me these are just problems with kernel implementations -- not of the design philosophy that HP wants to use here.
    • Well, kernel bugs will still get you, no doubt about that. You can compartmentalize the kernel itself, at least to some point, but that's kind of a separate problem.

      Kernel bugs aren't the big problem though. Look thru bugtraq and see what the kernel/user-app ratio of security problems is.

      Now look at how many of the kernel level bugs that are remotely exploitable. (Ummm, I mean exploitable from remote, not that they're unlikely.) Not to say that local problems aren't problems too, but they're a lot easier to manage.

      You're right about the bug whack a mole, but this time you'll be playing on a table with most of the moleholes plugged.

      The X thing is a bit of a red herring. The problem is that it has hardware access (disregarding fbdev and stuff like that), and hence (from a security POV) could almost just as well be part of the kernel. Solutions:

      • Don't run it. And don't allow other processes the priviliges it would/could have had. (This is easy with any MAC and even DAC system, X is always a bit of a special case.) The Selinux system is very fine grained and you can grant a subject a capability or not depending on its' type.
      • Compartmentalize X itself. To some extent this is getting worked at, but not (mostly at least) for that reason.
      (X apps are a little different from other apps, since they have other IO options (Atoms, cut+paste buffer etc.) Look up CMW (Compartmented Mode Workstation) if you want to get into that.)

      But even if you can't do a thing about X, this is still worthwhile. Think about someting like xntpd. It's root because it needs to open a low port and because it needs to be able to update the system time. But there's no reason that it needs to be able to, say, mount filesystems, read protected files, or load kernel modules. with traditional unix security we can't do that, but with this stuff we can. The attutude that "because it only fixes 99% of the problem, it's not worthwhile" has been a problem long enough.

      /August, once a sysadmin on a B1 system.

      • Re:There are major problems with compartmentalizat (Score:1, Insightful)

        by Anonymous Coward
        The thing is, even if kernel holes are not remotely exploitable, userland holes make it possible to exploit kernel holes locally...thus rendering compartmentalization irrelevant.

        Yes, kernel holes are implementation or design bugs that should be fixed. Ideally, compartmentalization would be a decent security solution for userland, although if the kernel is secure then finer-grained access controls are just as good (and IMO nicer).
    • The alternative, of course, is to ban the use of graphical interfaces on that system; but usually that is unacceptable.

      The real way of doing this is putting the hardware drivers into the kernel (frame buffer devices).
      No user process is supposed to access hardware directly, and if that meant we have no graphics, it would also mean no keyboard, text, or sound.

      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.

      That may be true, but it is only because of the nature of UNIX kernels. Kernels built with the principle of least privelege in mind (such as EROS [eros-os.org]) are definitely worth the fix, as it is quite unlikely to present new holes (and such a design is quite unlikely to have many holes in the first place)
      • The real way of doing this is putting the hardware drivers into the kernel (frame buffer devices).

        Isn't this what M$ did between NT 3.x and 4.0? And didn't this cause some stability problems, in that a required video driver for a server could crash the system? And didn't the UN*X crowd curse and swear when they did this? ;-)

  • Low confidence in anything from HP (Score:4, Informative)

    by Anonymous Coward on Saturday December 29, 2001 @02:22PM (#2762898)
    As a very happy former HP employee (voluntarily former), I have a very low level of confidence in HP being able to do anything productive in the Linux community. Just a couple of years ago I was explaining what Linux and GNU software was to senior people in what was then their Unix Development Lab. This was when I started having some real misgivings about the company.


    Over the next couple of years I saw high level managment with no comprehension of the Unix/Linux/GNU world whatsoever do some very strange things. The HP environment is rife with strange little tribes that lie and steal from one another with no real reason. Their Linux community is no different.


    And as far as HP contributing to the open source world - don't count on it. They will happily steal code, re-write it, and release it binary-only if they think they can get away with it. I've seen them do it. The whole damn company has a prima-donna attitude and will do pretty much whatever they think they can get away with.


    And as far as HP and security go - take a look at their own damn HP-UX OS for a security model and ask yourself why they think they can release a unique and decent secure linux product if they can't even release their own OS with any semblence of security?

    • Re:Low confidence in anything from HP (Score:5, Insightful)

      by Bruce Perens ( 3872 ) <bruce@perens.com> on Saturday December 29, 2001 @03:12PM (#2763004) Homepage Journal
      I agree that the HPUX folks do sometimes seem to lose sight of the fact that there is an outside world that, for the most part, doesn't run HPUX. But fortunately I work on Linux. HP has contributed a lot to free software: the IA-64 port of the Linux kernel is led by David Mosberger of HP and is all GPL, of course. HP spends about 1/2 Million per year just on salaries, benefits, and overhead for 4 of the key Samba developers. And a number of HP projects like Cooltown have come under the GPL. And of course they pay for all of my political efforts on behalf of free software - working on software patent issues, speaking, writing, etc.

      Bruce

    • AFAIK the B1 level code HP uses are from SecureWare (which they bought a number of years ago). It is the same basis as the code in OSF/1 (and subsequently Digital UNIX). I agree that HP never really understood security (their absence or non-participation in the X/Open and IEEE committees in the beginning and mid-90s talk for themselves).

      The SecureWare code is decent (I've once worked on it), but what I really would like is to get Data General to release their code (which is supposed to come from Adamax, now defunct I believe). THAT code I really respect and I believe it would be advantageous to get a real audit sub-system into Linux. I'll even settle for the AIX 4.x code for the audit sub-system, as it is already SMP-ready (I was the architect, so it would be extremely easy to retrofit it into Linux).

      Off-topic, I know....

      Roland B.
      • Last Christmas Eve (thanks /./search.pl) an Ask Slashdot [slashdot.org] of mine was posted which asked what we wanted to ask IBM for, seeing as though they were "offering" AIX as a plate. Not too many people came up with actual solid items we should have been looking to leverage, perhaps you have just come up with one and perhaps you are even the person to get the job rolling.
    • "As a very happy former HP employee (voluntarily former)" You forgot to mention disgruntled.

      As a current HP employee I would tell you that the quality of it's products all depends on the origin from within HP. HP is highly comparmentalized, and many of the things this poster comments about can be characterized as semi-accurate in certain circumstances. However, HP-LX comes out of the Virtual Vault Group, the guys who have been making the security software that is used by a number of major Banks for online banking and the like. It uses much of the same mindset and the same technology, so if it's crap...then I would suggest you abandone your online banking. It might very well be powered by HP.

      As far as HP contributing to the Open Source community. Like any other company, HP is driven by the all-mighty dollar (many times without a conscience), so they're going to do what they think will make them a decent buck. Right now, upper management thinks that Linux products and services will make them a decent buck, which is deffinately beneficial to the open source community whether their motives are pure or not.

  • HP was committed to Debian... (Score:4, Interesting)

    by leandrod ( 17766 ) <l@@@dutras...org> on Saturday December 29, 2001 @02:27PM (#2762913) Homepage Journal
    ...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?
    • HP does internal development on Debian and has contributed two Debian ports: PA-RISC and IA-64, both have been accepted for the upcoming Debian release. The secure Linux system will appear on more distributions than just Red Hat.

      Thanks

      Bruce

      • Thanks for the timely information, Bruce... but it still doesn't answer my question.

        Does HP commitment to Debian does not translate into Debian being used as a development, reference and first release platform? Or this has happened for some technical reason? Or for historical ones, like the effort being started before HP's Debian commitment?
        • Debian is the internal development platform. Released products are targeted to all LSB-compliant systems. This one is a little unusual, because it's a full Linux distribution. The target customer for this product wanted it on RH first - we asked.

          This product is just begging for someone to take the GPL component and run with it. It could be on Debian tomorrow, without the $3000 fee. Consider that a challenge.

          Bruce

          • Released products are targeted to all LSB-compliant systems.

            Doesn't that mean a lot of different distributions? Or is the development focus really aimed at various components in the kernel and on the outside that can be "dropped in" onto most distributions (e.g. the LSB-compliant ones)? I'm sure the target customer, being one who is swayed by the RH popularity, wasn't capable of just dropping in the individual components onto a RH (despite the "ease" of RPM) box, hence a whole distribution is needed. While as a geek, a whole distribition isn't of interest to be, I can certainly see how it gives PHBs that warm and cuddly feeling.

            Maybe you can clarify. I've read LSB and it certainly comes across to me as vague in this area, and I've heard conflicting interpretations that say yes and say no. Does LSB require the multiple runlevel separated directories of symlinks pointing to the init.d directory? As a security-conscious sysadmin, I do not want packages to touch my system initialization whatsoever (and some have). So I moved things around (and eliminated the symlinks altogether). The old directories are still there as a sort of "honeypot" but changes to them have no effect. Of course, for more security, I'm moving to doing more of the installs from source instead of packages.

            BTW, it is chapter 13, in section VII (LSB's weird two parallel section numbering scheme that isn't really hierarchical is certainly confusing), that by itself makes me want to avoid LSB. Why can't they accept other packaging systems? Why do they have to mandate the bloated and goofy one?

  • As I have said before... (Score:3, Interesting)

    by farrellj ( 563 ) on Saturday December 29, 2001 @02:30PM (#2762917) Homepage Journal
    HP is dumping HP-UX, and will be moving people to Linux...no one ever listens...

    ttyl
    Farrell

  • NSA selinux (Score:2, Interesting)

    by jlkinsel ( 546831 )
    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

  • More than just kernel modifications! (Score:4, Informative)

    by inburito ( 89603 ) on Saturday December 29, 2001 @02:37PM (#2762935)
    Typical slashdot ranting about gpl violations and how this is nothing new etc.. I wonder if anyone even read the article.

    This is much more than just a few kernel modifications but rather a full distribution that comes on 4 cd's. Instead of just having some hacks that improve security the whole distribution is build from ground up with security in mind.

    For example: You can't access shell unless you're on a console or use ssh. You can't access the configuration tools unless you are in posession of administrators private ssh key. Also, the installer forces you to set the system up with security in mind instead of installing everything and the kitchen sink..

    Best part of this is that it comes with support from a highly reputable vendor. Sure it has it's price tag but imagine the amount of work required to make a full distribution that's security conscious and backing it up with hp's name!

    And yes, you can download the source code that goes into kernel..

  • I'm not sure it helps enough (Score:3, Interesting)

    by markj02 ( 544487 ) on Saturday December 29, 2001 @02:39PM (#2762942)
    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.

    • In different words, the Linux and Windows kernels and daemons will have to be rewritten in something other than C or C++.

      May I suggest Cyclone [cornell.edu]?
      • Cyclone probably is too slow and too complex, and it seems to have a non-trivial runtime. Ada might be an OK choice, but it is also a very big language. Traditional language choices that have worked fine for writing kernels include various Pascal and Modula variants.
    • Why rewrite the kernel and daemons? What can be done in any high level language that cannot also be done in C or C++? Answer: nothing. So why would it be necessary to rewrite the kernel and daemons in another language?

      Simply providing security minded functions in a library, e.g. snprintf() and vsnprintf(), and employing them is all that is really needed.

      Kernel and daemon developers commonly use C and C++ because they are time tested tools that produce efficient and maintainable code for those applications. This isn't likely to change any time soon.
      • What can be done in any high level language that cannot also be done in C or C++? Answer: nothing.

        Why do we need safety belts and airbags? Can't people just drive carefully?

        Kernel and daemon developers commonly use C and C++ because they are time tested tools that produce efficient and maintainable code for those applications.

        Yes, indeed, we know exactly what kind of code real programmers produce in C and C++: systems full of security holes and buffer overruns. The fact that these bugs keep occurring even though programmers know better is exactly what demonstrates that C/C++ are not up to the task.

    • Purely as an engineering tradeoff ... Linux kernel was simply not designed with ensuring this kind of isolation.

      Of course it's a tradeoff, all information security is a tradeoff. What you're trading is ease of use, simplicity, and convenience for accountability, verifiability, and access control. Having these tools for security is less like dominos and more like roadblocks. The more you throw up, the more you slow down attackers, and the more that are going to give up before they do any damage. Your whole post indicates a desire for bandaids to hide real bugs.

      Linux implements traditional Unix security with some twists in its own unique way. We still have all the traditional tools. If you want to design a program to utilize things like chroot jails and capabilities you can do that today. HP's tools are just a nice addition to this. Linux having poor subsystem isolation is not the same as having no security at all. Now that I think about it, until we're all running Security Enhanced HURD, we won't have the overdesigned hyper-secure OS you're describing.

      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...

      Oh you mean like this [avayalabs.com].

      In different words, the Linux and Windows kernels and daemons will have to be rewritten in something other than C or C++. Sorry.

      Oops, sorry, I guess SE HURD won't be enough then. I'll just have to go back and see if I have my OS/360 tapes handy ;-)

      Regards,
      Reid

    • The problem with this kind of argument, though, is that you are presupposing that even the most skillful and most dedicated of programmers are careless and/or incompetent, in which case switching to a language that eliminates buffer overflows helps only very marginally.

      The point is that for any real world task, the problem-specific requirements dwarf all other considerations. The hard part is not some abstract "checking your input" -- the hard part is knowing what to check for.

      Programming is just hard. It's a complete fallacy to suggest that you can make it easier by shielding programmers from the implementation detail. Because it's exactly the implementation detail that we are being paid to get right.

    • The trade offs you have to make in basic compartmentalisation are hard to get right. There are so many different ways to break a "jail" on any system where the security is at the main OS level.

      Instinctively I've never trusted jail based solutions Linux or otherwise. If you want to compartmentalise build a small reasonably verifyable core and run Linux unpriviledged on it - its one of the uses for real microkernels (not Mach but something thats actually -micro-).

      • Alan Cox wrote:

        If you want to compartmentalise build a small reasonably verifyable core and run Linux unpriviledged on it - its one of the uses for real microkernels (not Mach but something thats actually -micro-).

        I Am Not A Kernel Hacker (IANAKH) but..

        Jonathan Shapiro's Ph.D. thesis work impressed me in this regard - a "nanokernel"-based OS that attempts to better support low-level security:

        It would be nice to implement a linux-like system on top of this, or perhaps use such a system to provide virtual machines on top of the hardware (like IBM mainframes or VMWare GSX Server).

    • We need better hardware architecture, too. Remember the iAPX 432? Every function was a protected island. Too bad the thing was designed to run Ada and the technology of the time made it too slow and expensive. We could do it well today.

      Bruce

    • Lisp dammit!

      What this world needs is a free Lisp OS (with the low-level stuff written in Modula or something if necesssary.)

      Too bad all the free Lisp OS projects deteriorate into arguments about implementation details...

  • Missed Point: HP all about business (Score:3, Insightful)

    by EchoMirage ( 29419 ) on Saturday December 29, 2001 @02:44PM (#2762951)
    There's a missed point in discussing whether or not HP-LX is practical or whether or not it's worth $3000. HP's target market is and always has been big businesses. What they've done in providing a secure, robust Linux implementation is to take away IT manager's number one fear about Linux: that's it's somehow "insecure."

    Practically speaking, it's safe to assume that nobody is going to run out and nuke HP-UX 11 off their servers in favor of this - HP-UX is still very far ahead of Linux (and some of its competition) in several important areas. However, for IT managers interested in considering a partial migration to Linux, this gives them a stable and secure path on which to begin to venture down, and undoubtedly one that's also covered by their existing support contracts with HP.
  • At $3000 HP-LX is too expensive for many to experiment with...

    That is only if you're afraid to do a little kernel hacking. Unless it's a binary only module (I doubt it, the're not hiding info about hardware) kernel patches should be available for Free. And really, $3000 beans isn't a whole lot for what sounds like a dreamy setup for internet boxen serving holy DNS and FTP. This is how internet services really should be ran by default. Unlike IIS that runs as user profile SYSTEM so that it can do impersonation (sorry for the M$ dig, but it's a really good example of how not to run internet services).

  • HP's kernel component is GPL-ed. (Score:4, Informative)

    by Bruce Perens ( 3872 ) <bruce@perens.com> on Saturday December 29, 2001 @03:04PM (#2762993) Homepage Journal
    The kernel component of HP's secure Linux is GPL-ed. Get it here [hp.com].
    The user-mode component is not GPL, but given the kernel API, it's pretty easy to make up the user part.

    Bruce

  • NSA's distribution (Score:4, Informative)

    by jd ( 1658 ) <`imipak' `at' `yahoo.com'> on Saturday December 29, 2001 @03:14PM (#2763007) Homepage Journal
    I've been using this since their earlier versions. It's extremely powerful, in that it provides for a heirarchical access control mechanism, rather than a mere on/off switch. (Unlike a certain other manufacturer, who shall not be named). The same account can have multiple login types, allowing a user to place fine-grain controls on what a given application they run can do under that account.


    The fact that SELinux (NSA's system) now uses the LSM framework means that it can be extended easily. You can either extend the SELinux modules or add further LSM modules of your own.


    It should be extremely trivial to provide a complete, and more flexible, clone of the entire HP security framework inside LSM, as all you're really doing is providing a set of capabilities to each thread, with pre-set defaults.


    In fact, you'd probably want to exploit SELinux' existing framework for this, so that you could create pre-set defaults on a per-user/per-login-type/per-thread basis.


    All in all, HP's setup doesn't sound novel enough to be worth 3K, but does sound intriguing enough to copy. Which, really, is something the LSM guys seem to already be doing. They've ported a decent portion of the OpenWall framework, which does a lot of this kind of stuff already.

    • Another "value added" component of HP's product may be that it is in fact a distro.

      The NSA's work has only been to patch the kernel, patch many of the common utilities, and create a few specialized utilities. It must be installed over a previous distro, which might discourage some less confident admins from using it.

      A 3 grand price tag might not be so bad, if HP is providing a turn key solution. For $3000, new admins can avoid the pain of patcing and manipulating their systems, and they also recieve support from HP. The NSA does provide any kind of support.

      Also, 3K is that much if the license permits unlimited implementation. If companies don't need to buy an additional license for each box, that is. Compared to licensing costs for Microsoft products, this would be fantastic. (I don't know if the license permits this. Like most slash readers, I didn't actually look at the article.:)

      While I don't see myself using this product, I see how other situations might warrant it.

  • 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.

  • Looks like "Secure Linux for Retards" (Score:4, Insightful)

    by dwbryson ( 104783 ) <mutex@cryptoback ... org minus distro> on Saturday December 29, 2001 @03:59PM (#2763135) Journal
    Ok, I feel that putting some peices of security in an OS kernel is a good idea. It allows you to have a lot of control over what goes on on a system, however it's not always the best idea for certain things. This distro it seems is that + *basic* system security...
    HP-LX includes pretty much every security tool for Unix imaginable, and defaults are set up with security in mind right out of the box. For example, HP-LX allows command shell access only via the system console or SSH (encrypted) connections. HP forces you to use OpenSSH by including a procedure for creating and installing the keys during the OS installation.
    This is a no brainer for anybody who is semi secruity concious. And
    HP-LX's installer won't install unneeded services. This is probably one of the best things you could do on your existing server; remove everything that you don't absolutely need.
    Comon people, every semi decent sysadmin knows this. Maybe I'm expecting too much from people (the number of people that complain to me about not being able to use telnet is disgusting) The added chroot jail stuff is neat, and no doubt helpful, but this distro really looks like it is not worth 3k. Any competent Linux admin could set this up with a couple days work. That doesn't mean his manager will approve... they would buy the MP distro because it would make them feel warm and fuzzy inside, even if their admin could design a better distro. When the article first off proclaims things like:
    Pros: Currently the most secure commercially available Linux system.
    I can generally discount most of what it has to say. Security is a process not a product.
    • Comon people, every semi decent sysadmin knows this. Maybe I'm expecting too much from people (the number of people that complain to me about not being able to use telnet is disgusting)
      Yep. But Joe, who installs 'that line-yucks thing' on his cable modem, live to the Internet, probably doesn't. Windows 2000, Linux, it's all the same; the lowest common denominator is going to be the user.
      • But that retardo kind of user isn't who HP is targetting with their $3k OS. They're targetting companies who want to spend less time setting up and securing their systems. Most of the features of this software could be replicated by an intelligent admin, but doing that takes much more time and effort. Any company running servers has to spend employee time to make sure those servers are setup properly and stay secure. I can see the logic in thinking that if you start with a smarter, more secure product that you will spend less employee time setting up and securing it.
        • True. It makes perfect business sense; the 'CTO' will see 'secure out of the box!' and ignore the 'unless you plug it in' line and plunk down their money. And lets face it, appearences count. How many times have you heard, said about budgets, 'spend it or lose it?' Or can you imagine the consternation on your sixty year old VP's face when you tell him, bald faced, that you didn't pay one red cent for your 'highly secure UNIX environment.'
        • And 2 years when the folks who build your "secure" box are gone, you have a company like HP still standing there. I think we can all agree that anyone can create a secure box with all the open source tools that are available now. But, creating the box is only part of the story. Someone has to maintain it, someone has to document what was done to the box (how was it build, etc). With HP-LX you get that in a box. Plug it in, install it and you are off and running in 20 minutes.
  • The Confused Deputy [upenn.edu] will stay confused, no matter how sophisiticated the ACL's are.

    The only real approach to security is a pure capability system [eros-os.org], and ofcourse the combination of pure capbility systems with safe languages [sourceforge.net].

    • uhm.. on UNIX, directories and uids exist.
      They should be used properly.
      Why "must" billing information be stored in
      the same place the compiler stores debug stats?

      UNIX accounting runs under a particular user
      (typically adm) and the information is written
      by kernel calls to the pacct file on process termination.
      There are very sound reasons for this separation
      of concern, like making it impossible for the
      compiler (or any other arbitrary program) to
      overwrite system accounting data.

      There is no reason for a compiler to have to have
      any ability to write to the accounting files.
      If that is considered a design requirement,
      then the design was wrong.

      In terms of debug/frequency stats, create a
      directory, make the compiler setuid or gid
      to be able to write there, and put the stats
      and ONLY the stats in that directory (
      you do the set(ug)id, at the very end,
      just to write the stats file as the last
      hurrah.) Or even just leave it public write,
      if someone wants to futz with your stats
      they really have time on their hands.

      I have nothing to say on the merits of capabilities,
      but the given example is quite weak, in that it
      Fixes a design error by creating an elaborate security
      mechanism. The simpler solution would be to
      fix the design.
      • There is no reason for a compiler to have to have
        any ability to write to the accounting files.
        If that is considered a design requirement,
        then the design was wrong.

        But the compiler IS outputting accounting information here.
        Its easy to claim that any design requiring a certain feature *nix cannot provide is wrong, but it sounds quite an absurd claim to me. You're trying to adjust the world to your OS, rather than write an OS that fits your needs.

        In terms of debug/frequency stats, create a
        directory, make the compiler setuid or gid
        to be able to write there, and put the stats
        and ONLY the stats in that directory (
        you do the set(ug)id, at the very end,
        just to write the stats file as the last
        hurrah.) Or even just leave it public write,
        if someone wants to futz with your stats
        they really have time on their hands.

        Problems:

        How is your solution preventing the original problem of a malicious user naming a billing filename as an output file?

        As long as the compiler 'changes hats' (Setuid/gid), the privelege-checking is quite complex and will probably result in VERY complex ACL's to achieve the goal.

        These stats are used for billing information, and people would thus be VERY willing to mess with them.

        All these security settings require root to set up, meaning that only a system administrator is capable of setting up any system involving security checks.

        Alternative approach:

        The mechanism used to identify (name) objects is that of unforgable, OS-implemented keys called "capabilities". These capabilities are much like *nix file descriptors, but they are never open()'d or close()'d. Having the capability is a necessary and sufficient condition to access the named object, the object does not care who access it.
        The above example, is very simply solved by capabilities:
        In order to name the billing file to the compiler, the user must have a capability to that billing file. In that case, the user is fully authorized to access this file. Obviously, the user does not have a capability to this file, only the compiler does, and since there is no way to forge a capability (just like file descriptors), the user cannot name the file he must not access, and may not confuse the deputy.

        Advantages:

        Users (code) can only express requests by access to a capability, meaning that code is only capable of expressing authorized requests. This means that there is no ACL test failure that may give false access to this user, as the mere ability to express a request is an indication of authority to do it.

        The only security test required at runtime is that the capability is valid, which is equivalent to the validity test of a file descriptor, nearing 0 time.

        Capability systems are in fact simpler systems, and many security properties of such can be mathematically proven, as demonstrated by Shapiro, in his proof of part of his EROS [eros-os.org] system.

        Capabilities have per-process granulity, rather than per-user granulity, and very fine-grained control of which objects every process has access to, thus the principle of least privelege is implemented.

        No need for a 'super user' that bypasses ACL's, because that would destroy the principle of least privelege. Every user can create objects and spawn capabilities to use those objects, and distribute them through every channel he has a capability to.
        This means any process with some minimal set of capabilities can set up a security system, not requiring any super user to bother, and killing the vast majority of threats involving a superuser.

    • Safe languages? Would those be languages in which you can only solve safe problems?
      • Safe languages are languages incapable of expressing things like buffer overruns or overrunning other memory, or invalid array indexing. This means they cannot express corruption of memory and are not volenurable to the vast majority of problems in most things today. Those languages, including Python, Smalltalk, Lisp, Perl, and others are incapable of crashing the machine (although sometimes C modules written for these do crash the machine), yet are Turing Complete and capable of solving any problem C, C++, or other unsafe language is capable of solving.

  • RSBAC & *plug* (Score:2, Interesting)

    by 21mhz ( 443080 )
    RSBAC [rsbac.org] is Secure Linux Done Proper (or almost there).
    Castle [altlinux.ru] 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.
  • Yeah, it is a pretty stiff prize $3000, but actually for Linux adoption in the market place, I think it is a Good Thing[tm]:

    You know how PHBs think: If it's free, then you can't make money off of it. If HP is able to sell this at $3000 a piece, maybe they will get their eyes opened for the possibility that there is money in Free Software.

  • 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 [hplx.net]. 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.
    ---
    • Actually, for the longest time the nickname has been HP-TLX (as in Trusted Linux), some have shortened it to HP-LX, and there has been a campaign lately to force people to use the full name HP's Secure Operating System Software for Linux. It is anyone's guess as to which name will stick in the long run.

  • Secure Linuxes (Score:2, Informative)

    by ibex42 ( 135204 )
    At the Linux Showcase in November I attended HP's presentation on Secure Linux [linuxshowcase.com] and if you sweet talked the HP guys they would unlock the secret cabinet and give you a copy of Secure Linux. I also did a term paper on SE Linux last semester.

    The two OSs are fairly similar in what they hope to accomplish -- isolate the risky software and users from the rest of the system so if something bad happens it doesn't take everything down. From the sound of the HP presentation, this is all HP Secure Linux does. You create compartments and then specify what the compartment can do. You can do the same thing with the NSA's SE Linux and much much more. I was really impressed with the flexibility offered by SE Linux. You can setup your system with about any security policy you like. The biggest problem is the great complexity. You need to do a good deal of research before even thinking about modifying the sample security rules that come with SE Linux. There are thousands of rules in the included security policy. This is where HP Secure Linux probably has an advantage--it's a bit simpler to user. Though I haven't had a chance to try it out yet.

    You don't really need to pay $3000 for it either. The kernel patches are GPLed and part of the kernel security interface used by SE Linux also (NSA and HP have cooperated here). You are really paying for the tools, but those are just programs that make certain sys calls. It shouldn't be a problem to write your own open source versions. Though there might be a nice gui that would take more work to create.

    If you are interested in secure linuxes also take a look at Immunix [immunix.org] and EnGarde [engardelinux.org]. Both also have kernel level security controls, but not to the level of NSA Linux. Immunix has a comparment system like HP Secure Linux called SubDomain. EnGarde uses the Linux Intrusion Detection Project.

    A paper doing a detailed comparison of the four would be welcome!

    • I've been looking at doing my own LFS [linuxfromscratch.com] similar to kaladix and potentially using [kaladix.org] what might be a smilar patch and tools to this hp stuff mentioned [solucorp.qc.ca]. I need to go checkout this hp patch and spend some time with it to find out what its about.

      At one time I looked into SE Linux but noted there was some problem with using LVM with it due to attributes that were used on files, But maybe this has changed? I suppose I could go look again.

      I like the idea of setting things up my way (LFS) anyways and using it as the base server and having other virtual servers.
      • In the SE Linux built against 2.2, PSIDS were stored at the inode level, which meant that a security resolution below the filesystem level was only possible using ext2.

        The latest versions use the Linux Security Module (lsm), like LIDS, that hooks in at the VFS layer. so far, ext2 and ReiserFS have been confirmed to work. The only requirement the fs is persistent inode labelling(?-my terminology is off-?), but (IIRC) ext3 and xfs have also been tested.

        Check the mailing list for details.

  • Immunix (Score:2, Informative)

    by Crispin Cowan ( 20238 )
    Immunix [wirex.com] is our security-hardened Linux system. Immunix offers a security confinement mechanism called SubDomain [wirex.com] which is similar to SELinux [nsa.gov] and HP's Virtual Vault [hp.com] technology, which is what is incorporated into their HP-LX product. SubDomain is "in between" SELinux and HP-LX, in the following ways:
    • Complexity and Flexibility: The more complex a product is, the more flexible it can be. SubDomain is less complex to manage than SELinux, but offers more flexibility than HP-LX.
    • Price: SELinux is free, Immunix Systems are $90 each [elinux.com], and HP-LX is $3000 each.
    Immunix also features other security protections:
    • StackGuard: resists most buffer overflow attacks.
    • FormatGuard: resists most printf format bug attacks.
    Crispin
    ----
    Crispin Cowan, Ph.D.
    Chief Scientist, WireX Communications, Inc. [wirex.com]
    Immunix: [immunix.org] Security Hardened Linux Distribution
    Available for purchase [wirex.com]
  • What's most important about the price tag, is that HP is backing a secure version of Linux. It's not really 3K for some fancy GUI tools, but 3K for the tools and for HPs guarentee that this is actually going to work.

    It's not really that expensive. In fact, I'll probably recommend it to the company I work for. If your company is security conscious, and you don't want to have to maintain something, then this seems like a great option.

    This is probably one of the first really good business plans I've seen with Linux. The greatest part is that HP didn't try to mess around and not release the kernel stuff. So, they've helped out the community by adding a cool concept (I always hated that Linux does have jails) and they also are delivering a good, reasonably price, product.

    I am of course assuming that this software works :)

    If you do the math though for a server running Windows NT plus an email server, web server, and remote admin package that would be as robust as what Linux has, then it's a no brainer which one is cheaper.

    Especially since alot of software is based on the number of users (especially email suites). So you kind of end up getting screwed when you hire more people.
  • have been known to be risky for a long time. It is my hope that some of these ideas will be incorporated within the next kernel, or show up as modules. For your front line servers running apache, ftp, sendmail, and maybe generating content on the fly via a database - this would make sense to isolate those issues there. It would also seem quite reasonable to run those services known to have high risk on a virtual machine, reducing the compromise to just that layer (hopefully). Anyone had a great deal of experience with that route? I didn't start using Linux because my other OS was too secure....
  • 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.
    • You are right that HP-LX has an audit subsystem. Actually, this audit subsystem can be run on any Linux system. It is not specific to HP-LX.

      None of the code for the audit subsystem in HP-LX is from SecureWare. But the lessons learned from SecureWare/VirtualVault is what motivated this audit subsystem.

      The audit kernel driver and the audit daemon are all open sourced. The reduction program is not open sourced. (I hope to change that in the future :-) But I have battle on my hands on that one).

      The goal of the audit subsystem was to get the audit data out in any format that the user wanted. You could view this audit data in a format that you wanted or you could pipe your audit data into an IDS system of your choice.

      HP-LX audit is 1.0 software. It is missing many things. But, after some evaniglizing (sp??), it was a 6 month effort from the "go" word to out the door. So, somethings needed to be cut back on.

  • Surprised nobody's mentioned TrustedBSD Project (Score:2, Informative)

    by Anonymous Coward
    More info here [trustedbsd.org].

    Much of the work is to be rolled into a future FreeBSD distro. And that's released under the BSD license -- than which you can't get much less restrictive.

  • You really have to have applications designed to use a secure system like this. Programs need to be divided into multiple, intercommunicating components, with narrow interfaces and different privileges for different components. Security-related, trusted code should be small and do as little as possible, so that it can be thoroughly checked and seldom modified. Big code should be untrusted and run in minimal-privilege boxes. This is the basic architecture of secure systems that actually work.

    For example, a mail handler should be composed of several components in separate security compartments:

    • The mail database, which can talk to its own files, can accept interprocess connections from other local mail components (and can verify their identity), and can't talk to the network. The database contains mail from multiple users, so it's trusted in that sense, but is more of an object than a subject; it isn't allowed to initiate anything.
    • The external connection authenticators, which receive initial POP and SMTP requests, process them until they authenticate, and then fork off a separate process for each connection. These are trusted processes, and they perform only security-related functions. That's key. Note that this is roughly how UNIX "login" works.
    • The per-connection communication processes. Each of these can only talk on the network connection it inherits, and the connection to the database it inherits. The database can check the credentials of the process, which are set by the authenticator and cannot be changed by the per-process connection. These processes do most of the work. They are untrusted; that is, they have no security responsibilies and cannot corrupt the rest of the system. The stuff that is always breaking in Sendmail goes here.
    • (other components as needed)

    That's what NSA Secure Linux is intended to support. DoD secure systems have been built like this for at least two decades.

    Again, and I cannot overemphasize this, the key is that the trusted components must be small. All other architectural considerations, including performance, must yield to this if you want security.

  • Comment removed based on user account deletion
  • 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.

  • Because of all the labor and brain work involved. This a VERY good thing for shops and ISPs that standardize on HP to do.
  • I'm surprised that no one has addressed one of the big reasons for this release. This is to compete with Sun's Trusted Solaris [sun.com] in trying to land more defense contracts and customers. For one or two cpus it's about the same price. However, sun has been developing this much longer and may be able to scale to larger number of cpus better. If we could only convince those defense people to stop using SunOS now.

  • some clarification (Score:2, Informative)

    by joubertb ( 44326 )
    First some clarification.

    HP-LX has no VirtualVault code. There is nothing in HP-LX code that is derived from VV.

    A trusted/secure OS should not be your ONLY security mechanism. It is just a part of the overall architecture.

    So, what were the goals of this product:

    VirtualVault covered the ultra security needs. But at a cost. You needed to intergrate your applications on a VV. You had to teach your sysadmins about VirtualVault. Many smaller shops could not justify the cost of these. So an alternative was created by HP.

    Some form os security is better than no security at all. So, what HP wanted to do is lower the complexity of the security mechanism and raise the ease of use. This would allow people to get applications up and running quick on their machine and not have to retrain their systems on a new os.

    So, the product had to be:
    1. Help protect services on the network boundry. So, this is not designed as a multi-user system. It is designed to protect any type of service that is made available on a public network.
    2. Easy to use. Without this, it would be an interesting product, but acceptence by the non-security folks would be hard.
    3. Security should not be intrusive. So, as little code change as possible. By this I mean, try not to make changes to user space programs. The admin should be familiar with the environment that he is running in. Only 2 programs are changed, init and xinetd.
    4. Sometimes security had to be relaxed in order to keep it easy to use.

    These were the four high level drivers for this product.

    From a feature set, there are three major components:

    1. Containment. Protecting agains ALL buffer overflow attacks is difficult. So, lets contain the damage. Compartments helps us issolate the application from other applications/subsystems on the system.

    2. An audit subsystem to be able to watch what is going on on the system. Collection audit does not help if you can't do anything with it. So, it had to be flexible. It is in it's early stages.

    3. Lockdown. This mean, locking down most of the permissions on the system. Use tripwire to monitor what is going on on the system. Turn off most of the service that are needed. Generally, do whatever you would do to lockdown a system that is put on a public network.

    This should give a little insight into the motivation for the product. This should help shed some light why some decisions where made. The goal of this product to to find a right balance between "ease of use and security". You can be the most secure product, but if it is difficut to use, it will be cast aside. HP-LX is an attempt to achive this balance. More work is needed, but it is the first step...

Slashdot Top Deals

Disclaimer: "These opinions are my own, though for a small fee they be yours too." -- Dave Haynie

Close