Slashdot Mirror
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?"
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?
Doesn't HP have to release their source code to comply with the GPL?
Shh.
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"?
...here.
b&
All but God can prove this sentence true.
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.
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.
Is your company running tools written by ma
- 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
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?
some of us, will be pleased to wait for the GNU version, at a cost of: free, as in download.
...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?
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
Youre right, but whoever buys it is then free to do whatever he wishes with it, including give it away, sell it for less (or for more), or print it out and use it for napkins. So whats the point of HP selling it when all they have to do is make one sale, then the buyer could turn around and give it away to thousands of people? They cannot stop this from happening, because the code must be GPLed, and the GPL allows that.
Liberty in your lifetime
HP is dumping HP-UX, and will be moving people to Linux...no one ever listens...
ttyl
Farrell
CAN-CON 2019 - Ottawa's only book oriented Science Fiction Convention! October 18-20, Sheraton Hotel, Ottawa, Canada h
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
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..
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.
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.
i never said you couldnt do that. But do you think some giant corporation that buys a HP solution for their enterprise is gonna go and put this distro up on some ftp just for the hell of it? unlikely.
Charging 3000$ for the CD set means that 99% of the jackasses who would use the GPL in order to buy something and then turn around and release it for free can't afford it while the 1% that can have to pay a pretty penny to be jackasses. I can pretty much assure you some jackass Linux zealot with no understanding on the GPL is sitting in his bedroom right now trying to figure out how he can raise 3k so he can be a folk hero by releasing the code an evil company is keeping secret. At the very least HP is giving some idiot something to do.
I'm a loner Dottie, a Rebel.
So this seems like it would have prevented the
website defacement to Linuxtoday and other glorious
VA sites. How come VA did not use either the NSA or
the HP product? Think they know too much, eh? Or
are they running out of cash faster than anyone
realizes?
Well, whaddya know, Linux Today got hacked 2 weeks
ago.
excuse me but you are way off. anything I write that doesnt use sourcecode from a GPL product can be sold as closed source-evilware or whatever. I love this how you zealots create FUD about the things you hold dear.
No they dont have to, and if they do it will be because they are gracious to the rest of us and NOT because you whined about it.
READ THE GPL you twit.
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).
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.
On the whole, I find that I prefer Slashdot posts to twitter ones because I don't get limited to 140 chars before
The user-mode component is not GPL, but given the kernel API, it's pretty easy to make up the user part.
Bruce
Bruce Perens.
Uh.. How about you go download the GPLed code from hp's site right now instead of speculating about what people could do.
However.. You are not going to get the closed source administration tools without which the kernel mod's are almost worthless. You also don't get a fully set up distribution with all the configuration and will have to duplicate all the effort that went into creating it.
If you want to be reasonably sure that your version is secure you'd have to perform extensive testing on it and have a lot of really smart people take a look at it. This is actually the easiest part as it follows normal linux development method. Still, whose ass is on the line if things are not as secure as they should be?
And you can bet your ass that anything that doesn't need to be GPLed is not and it comes with a very strict HP license that specifically forbids any disassembly, resale, etc.. Support contracts probably also include a clause that you have to have purchased the official hp distribution..
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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Why not? They've paid for it, sure... but once that's been done it's no money out of their pockets to give it away to other people. And since the GPL allows it, I don't see any reason why they wouldn't other than the rather irrational view that if they had to pay so much for it, then so should everyone else. But giving it away in that case would only be injurious to their pride, not their actual financial situation.
This raises what in my mind is an interesting question: is it possible to pirate GPL code? That is, say a school buys this and then some student who has access copies it and then gives it away. Since the student hasn't personally forked over the $3K, he's not going to be motivated by pride to not give it away. Further, keeping in mind that all he would have copied is stuff that was GPL'd anyways, would the student have actually done anything wrong? If not, then it's as good as certain that HP-LX will be freely available in a relatively short time. Apologies for digressing from the topic somewhat, but I believe that such a scenario illustrates the can of worms that might be opened by charging for a GPL project.
File under 'M' for 'Manic ranting'
That's something I never expected to see on Slashdot -- anyone deciding that going for a product by the NSA is a _good_ idea.
You're still not safe though, since the kernel is designed to permit it if you decided to install it.
On my large cluster site, I run TrustedBSD, which already has all the features talked about here.
Why keep on re-inventing the wheel?
Ya gee i'm sure morgan stanley or citicorp is really gonna put up a big high bandwith ftp server and put the distro on it just becuase "information wants to be free dude!".
Get real.
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.
- "Never let a computer tell me shit." - DelTron Zero
Not installing X doesn't cause the kernal to take note, and alter how it treats the system calls in question.
Vintage computer games and RPG books available. Email me if you're interested.
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.
-Justin
That's enough posting for now lads, there're trolls afoot.
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.
You can't get a blue screen on a black and white monitor.
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.
"An object declared as type _Bool is large enough to store the values 0 and 1." -- 6.1.2.5, C99 standard.
The Confused Deputy will stay confused, no matter how sophisiticated the ACL's are.
The only real approach to security is a pure capability system, and ofcourse the combination of pure capbility systems with safe languages.
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) 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)
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.
My exception safety is -fno-exceptions.
Would it kill slashdot to get an HP Logo?
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.
Employee of Inrupt, Project Release Manager and Community Manager for Solid
You're partly right.... But not completely ;)
The whole HP distro isn't GPL.. Therefore you if you did copy it, you would be in breach of the licence.. You're right when you say it isn't possible to pirate GPL code.. If the whole thing was GPLd, then there'd be nothing to stop people copying it and distributing it freely..
David
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.
---
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 and EnGarde. 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 always wondered about this scenerio under the GPL:
Party A writes software Foo. He sells a Foo binary to Party B. Party B requests the Foo source. Party A then gives Party B the Foo source, as dictated by the GPL.
But then Party C asks Party B for either the Foo source or the Foo binary. Is it necessarily legal for Party B to give Party C the source or binary?
I agree that if Party A had given Party B the right to redistribute the binary to Party C, then Party A would have to also give Party B the right to distribute the binary to Party B. But what if Party A never grants B any distribution rights whatsoever (including to the binary)? Can it then be said that Party B cannot redistribute the Foo source?
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? ;-)
Method of processing duck feet
- 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, 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.
Immunix: Security Hardened Linux Distribution
Available for purchase
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.
int func(int a);
func((b += 3, b));
I've been looking at doing my own LFS similar to kaladix and potentially using what might be a smilar patch and tools to this hp stuff mentioned . 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.
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....
Freedom is merely privilege extended unless enjoyed by one and all.
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.
-- Roland Buresund MBA, MCMI, CISSP
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.
Not if you do a recompile and do not include support for such features (e.g., DRI). I guess if you were really worried about it, you also could build a monolithic kernel with no loadable module support.
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.
XFree86 pokes around in /dev/mem and is perfectly capable of crashing your computer, giving root access, and destroying your hardware. In short, the "UN*X crowd" (aka M$-hating slashdotters) are fucking full of shit.
Bruce
Bruce Perens.
For example, a mail handler should be composed of several components in separate security compartments:
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.
No, you would need to use capabilities (lcap and stuff) to stop any processes from giving themselves IO priviledges. You can't turn off iopl(2) and ioperm(2) support in the kernel config, but you can remove the capability once the kernel is started, I'm pretty sure. Also, you have to disable module loading (with lcap, so you can do this after the mods you want are loaded), otherwise someone who gets root can load a kernel module that can do anything and everything they want.
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@cordes ,
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).
Just to mention Argus Pitbull / Pitbull LX from Argus which is also available for Linux...
;)
;)
And... no I'm in no way affiliated with them...
But I have to admit I attended an Argus Pitbull Training.
Bruce said "they pay for all of my political efforts on behalf of free software - working on software patent issues, speaking, writing, etc."
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.
Know ye not that ye are Gods???
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 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.
Democrats and Republicans only disagree about how to enslave you
For those without the time to read what HP-LX really does:
1. Non - standard, Different stuff:
- Forces you to add a label to all processes (in a kernel structure). A process can NOT change its label (even if it is run by root). All processes with the same label are said to run in a "compartment". LAN cards are also associated a "compartment".
- lets you define what files can be read / written by a process in a compartment (Additional to std permissions). These rules cannot be broken even by root.
- Lets you define what sockets can be opened between compartments (kind of a intramachine firewall). Lan cards are also compartments so you can very well avoid, say, something running as root in a compartment to open a socket back to the internet. These rules cannot be broken even by root.
- Defines an additional "capability" to allow all previous rules to be changed. A process with this capability and running as root can change the previous rules. The capability is given to init, but as soon as a process drops it (which init does for almost all processes) it cant be recovered. The way this is implemented, this capability is kept for the console getty (for local administration) and for a modified ssh daemon, that keeps it if you are using the correct private key (for remote administration).
- Capability - enabled modified ssh daemon (see above).
- A kernel auditing facility.
- Assorted admin tools related to everything described above.
2- Nice to haves:
- a pre-hardened (as in Bastille), pre-configured Red Hat linux distro.
- pre-installed tripwire
- integration tools (for the previously mentioned environment) which also help you with the chroot stuff. Chroot is used as an ADDITIONAL security method. NOT as the primary one.
3- "Security is a process" comments:
Lets hear from Bruce Schneier himself (Secrets & Lies, p. 133-134)
" A secure operating system, and hence a secure computer, has several key components. One is a strong mandatory security mechanism of a more general model that the formal models discuss"...
(See compartment stuff above)
"The second key component is a trusted path. This is a mechanism by which a user or a process can interact with a piece of trusted sofrware, which can be initiated by either the user or the trusted software and cannot be impersonated..."
(See "capability" stuff above).
4- Conclusion
Draw your own.
A. Coward
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...
You're a fucking idiot, with nothing indelible, nothing that will remain once you leave the small, small patch of nolife that you now barely inhabit.
To not know telnet is not disgusting. To know that one must live as you is the fright which can never be remedied.
Fuck you, and your small existance. Smaller than the smallest thing which no girl will ever see as they laugh at you.
Stay suck, baby.
No, not neccessarily.
The trick is boxing the applications so they can't do much damage. On (for example) selinux you can grant xntpd permission to do just what it needs to do its' job, and nothing more. Maybe you don't want to let it read world-readable files (the only file it has any business reading is its config file, so why let it do anything else?), or fork, or whatever.
This means that a cracker would have to be really lucky. He needs to find an exploitable application that gets to use an exploitable local feature.
Even if he manages to turn xntpd's image in memory into a shell, he'd end up with a really stupid shell which basically can't see any of the filesystem, can't run commands, etc.
"An object declared as type _Bool is large enough to store the values 0 and 1." -- 6.1.2.5, C99 standard.
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.
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 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.
> Either post links [vnunet.com], facts
> [cnn.com], or other references
> [linuxtoday.com], or don't expect
> anyone to listen to you.
Some of us are here to learn how to flame from the experts.
The phrase "use it or lose it" comes to mind.