Slashdot Mirror
Auditing for Linux?
steelwraith asks: "I'm a contractor working for a DoD agency, and there has been an on-going firefight over whether to allow Linux to be used withing the agency, with a possibility of this spilling over into DoD as a whole. Does anyone know of a project to create or port auditing into any of the Linux distributions? This is a major hurdle to the widespread adoption of Linux in the government; while it has a toe hold in places already, I fear it could be cut off before it has a chance to show its worth."
"A quick search of several sites (I'm under the gun, so I don't have a lot of time to do research) shows that there are no add-ons to Linux to allow C2 level auditing (a la BSM in Solaris). This is one of the primary arguments left for the side that want to deep-six Linux in the agency (on top of the requirement for a vendor integrity statement of some kind)."
The biggest hurdle to getting linux on board is getting a DII COE kernel developed for it.
Now for those who don't already know, DII COE stands for Defense Information Infrastructure Common Operating Environment. The project is done by JPL and maintained by DISA.
The DII COE kernel overlays the OS, and provides a common set of utilities and security measures to help administrate a box. The government is a little tired of an application taking up a whole machine, and wanted more flexibility. The DII COE provides a set of tools to do this, providing more security to boot.
And it may one day get to the point where all DOD systems will be expected to run DII COE, and all applications are to be delivered in DII COE's package format. And if that happens, Linux will be locked out.
NT4 is C2 certified, both standalone and networked.
P -CSC-EPL-99-001.html
http://www.radium.ncsc.mil/tpep/epl/entries/TTA
The mainstream Linux community (including the developers that have brought it this far) have no real interest in military-style security. This is one of those cases where the end user (the DoD) should scratch its own itch.
They have the means (money) and the motivation (money + security) to do this themselves or sponsor somebody else's efforts. The result would be an OS that exactly matches their requirements and that they can continue to mold to their own purposes without relying on some vendor.
Of course even if they don't do this some companies will. SGI and IBM have a lot riding on Linux and they need to sell into big government accounts, so they'll take care of it.
It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. - Abraham Maslow
The network side, though, is a tad more complex. :) It is posible, for example, using the features in the various trffic shaping tools, to specify that user X has access to 20% of the bandwidth for FTP, 0% for the web, and 5% for ssh. You can further state that the 20% FTP bandwidth is split into 15% for the local server, 5% for the corporate off-site server, and 0% for everything else.
Whilst this does not constrain what the user DOES with the net access that's been granted, they have effectively been given access to named resources at named sites. No other access exists for that user, because they have zero bandwdth to do anything with.
As for the assurance, I can certainly see that side of things. I imagine a group such as SuSE or Debian have the capability and resources to go through their distributions and formally prove it secure. (Red Hat, whilst good at many things, are not number #1 on security holes.)
Alternatively, I can see some group springing up to produce a watertight Linux distribution, specifically designed and tailored to meet the B level classifications. (Might be fun to do that, actually....)
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)
It's a really neat tool! Horrible interface, though. If someone wants to write a decent interface (even if it just takes a comprehensible /etc configuration file), I am sure that a lot of admins would worship at their feet.
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)
They're calling it "Orange Linux", after the "Orange Book" that describes the requirements.
Christopher A. Bohn
cb
Oooh! What does this button do!?
Yes, thanks for doing that Tom.
A couple of clarifies...The code known as OB1 is extracted straight from TRIX 6.5.x (our Trusted B1 product).
Its called "Sample Source" since its not a complete B1 product and if it was it could only be compiled into the Irix codebase. We thought it would help those interested in trusted systems if we made some of our code available to provide a "sample implementation" of something that is known to work.
richard.
PS. We were all laughing (well I was) that the first posting described my boss as a gentlemen...
You don't -- but C2 / B1,2,3 or whatever doesn't really help either, because they can't really check the code line for line to make sure there are no bugs. And one stupid bug can screw everything up.
When it comes to classified systems, you need to consider more than the "security classification", which really only serves as a cool bullet in the feature list. You need to consider the vendors track record, especially with regard to security and bugfixing.
SGI is supposed to be working on C2 certification, which they're hoping to get into the mainstream so that pretty much any distro that wants it can be C2-certified, and also B1 or B2, I forget which (whichever one is legal to export). They are doing this specifically because they have reason to believe they can sell Linux to the DoD.
Unfortunately, I can't find anything confirming this on their site -- this is information I picked up at the recent SGI "Linux University" travelling show. If I recall correctly, and they manage to keep to their projected timetable, we should see the C2 Linux become reality sometime later this year, and Bn in 2001.
--
perl -e '$_="06fde129ae54c1b4c8152374c00";
s/(.)/printf "%c",(10,32,65,67,69,72,
$_="06fde129ae54c1b4c8152374c00"; s/(.)/printf "%c",(10,32,65,67,69,72, (74..76),(78..80),(82..85))[hex $1]/eg;
While tripwire is a nice tool (although some people say it's showing its age and there are newer tools now available) what it does is not going to satisfy anything close to C2-level security. Tripwire tells you that someone was messing with your system and by then it's too late (i.e., tripwire tells you that you need to shut the barn door because the theives have stolen your horses).
What our contractor friend is looking for is (I believe) something on the order of access control lists that prevent the touching of the files and directories in the first place. I would think that a kernel module could be written that looks at between user space I/O requests and the filesystem and [dis]allows I/O operations based on the security capabilities granted to the user process. Load the module and your I/O requires properly setup ACLs; unload it and it's back to the garden variety UNIX file permissions (unless you're root, I guess, in case your ACLs are set up incorrectly).
Personally, I would love to see this available on Linux. ACLs and rights identifiers were one of the coolest things (IMHO) under VMS; you could really tailor security far, far better then you could using the simple Read/Write/Execute/Delete access you could set up for objects. Having something like this on Linux (or most Unices, actually) would make it easier to dole out accounts with varying levels of privilege and go a long way toward assuaging those who complain about Unix having a superuser.
--
CUR ALLOC 20195.....5804M
You are right, I was being a bit harsh. I'm sure there are a lot of auditors that are technically inclined. I just haven't run into that many of them. Most of them that I've run into have an accounting background and view computers as just a tool for that purpose. It is worth noting that if your Anderson Consulting in the UK is part of the same Anderson Consulting that is one of the 'big five' in the US, that they are also in the IT consulting business. Undoubtedly people on that side of the business should have a lot more of a technical background than people in the financial/accounting side.
Is it because the Big Five don't know how to spell Linux or is it because they aren't really doing their job?
I work in a big financial IT shop where we have big five auditors in occasionally. From what I've seen the answer to your 'or' question is 'yes'. Most of the auditors that come in are utterly clueless about Windows, let alone anything non-Windows. They can basically muddle about a little in MS-Office and that is about it. I've actually had to help some of them import CSV files into Excel, including helping them figure out how to load files off of a floppy disk and unzip them.
I've also seen them sit down at a SparcStation and be rather puzzled when confronted by the login box... Then turn the power off, watch it reboot and come back up to the same point. At which time I told them 'that isn't a PC'. Blank expression. 'You can't run Outlook or MS-Office on that, it isn't a PC'. Blank expression. 'Use that PC over there'. Auditor shuffles off looking confused...
I would think that the vendor integrity statement problem could be gotten around by purchasing shrinkwrap box versions and then having the vendor of those distributions sign the paperwork the government wants.
Someone should talk to the distribution vendors to see what efforts they could make to add and document C2 auditing to their distributions. I'd think if they thought they could get a significant number of sales to government agencies they would view that as a good investment in resources.
SGI has a site with some sample code and documentation about implementing a B1 secure system over here which may be of interested in this conversation.
Yes, complete with lots of backdoors that are emergent properties of convoluted makefiles, or something ( like that compiler that compiled backdoors into itself...)
Choice of masters is not freedom.
I recently linked the web page for SGI's B1 sample implementation on OSS. Here is the URL http://oss.sgi.com/projects/ob1/. You can find some source for a sample implementation.
I'm a little bemused by the extreme concern of DoD in computer security. Granted that they have many secrets to hide and their war-potential to protect. However, I would note that most security breaches are caused by human factors, whether deliberate or accidental. One can point to the example of an ex-CIA director who left incriminating files on a laptop. Also draw the analogy that engineers have concluded that more car safety technology is reaching points of diminishing returns as only 10% of accidents is attributed to mechanical failure and the rest mostly to the idiot behind the wheel (alcohol, road rage, sleepiness, whatever). In the same way I fear that network paranoia (while important and a hard target) is blown out of proportion to the more obvious risks of human failability. I would like to be comforted that the military has on-going *HUMAN* processes to keep improving the quality of their people rather than hoping the next Y2K bug doesn't accidently triggers the nukes. Invest in brains, not silicon bullets.
In a broader view, what is it about technology that foster the simplistic magic pill approach? In any complex situation, after you eliminate the obvious weaknesses, there will be many vulnerable points of attack and more exotic technology in lieu of awareness training could create a false sense of security. Blind faith, whether religion, technology or dogma seems to be a point of hubris.
LL
Me: What is the point of having a cheap bicycle lock that you are absolutely, positively sure will not stand up to a determined attempt to break it?
You: Well, the point is, it stops a casual thief.
No. That answers the question, "What is the point of having a cheap bicycle lock?"
You said there is a place for a system with low security but high assurance. I am trying to figure out what that would be.
In other words, why would you buy a $20 bicycle lock, and then pay $5000 to verify that, yes, it really is a cheap bicycle lock?
Similarly, a situation where you don't do much to prevent people from coming and going, but are sure that their activities are on a security tape (for example, an ordinary bank) calls for low security, high assurance.
I'm starting to see where the confusion is coming from. You're using terms in a different way.
Security is a multi-part thing. Exact definitions vary, but it is generally defined to be the sum of integrity, availability, authenticity, and accountability. Accountability includes audit. In other words, keeping careful track of who comes and goes is a part of security.
Assurance is how sure you can be that the security features of your system actually work as advertised. Not, "Do we know who took the money?" but "How sure are we that this camera we're thinking of buying will do the job?"
I suspect that levels like A1 describe even better assurance than C2 -- but that you can't get credit for those levels of assurance without also having A1 security.
Moving from Class B to Class A is entirely about adding assurance, and not about adding new security features. IIRC, the big thing about Class A1 is that it requires a formal mathematical proof that your security features work.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
FWIW, it seems worthwhile to point out that "Orange Book" classifications are not all that well thought-out. The problem is that they tie increased security to increased assurance.
... it is often useful to have a low-security, high-assurance system ...
:-)
That's right, it does. Think about it. Why do you increase your security? Because you have something more valuable to protect. If it is that much more valuable, wouldn't you also want to know your increased security also works?
It is extremely difficult to establish a high-security system while simultaneously having a high assurance that it is correctly implemented.
Yup. Life is hard.
It is? What is the point of having a cheap bicycle lock that you are absolutely, positively sure will not stand up to a determined attempt to break it?
I honestly can't think of a situation where you would want to pay a lot of money to be sure your security system isn't all that good. If you can think of an example or two, please, enlighten me.
Indeed, if audit is the only really interesting property in this case, it sounds as though low-security (mostly logging) high-assurance (logging cannot be defeated even by 'creative' users) is exactly the solution that is needed.
Congratulations, you just described Class C2 protection.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
I haven't hear much about Linux production environments getting hammered by any of the Big Five during year-end IT audits
Wrong kind of auditing.
DrLunch.com The site that tells you what's for lunch!
It's been a while since I was into all this security stuff, so I'm a bit foggy on what C2 requires in the way of accounting. However, the contractor I work for has had us securing our SGIs according to DoD standards. Now, I don't know whether these conform to C2 or not, but they're very very tight boxes now.
From what I've seen in securing these SGIs, I don't believe I'd have any problems tightening down my Linux boxen at home in the same way. As far as accounting goes, the real issue is that a sysadmin can tell who the physical person is behind that user name. That means getting rid of shared accounts, strengthening passwords, etc.
Granted, you won't be able to get a keystroke by keystroke log of a user's session, but that would be too much information anyway. There are, of course, commands that you'd want to monitor and most of these provide logging themselves (such as 'su'), while it would be easy to write wrappers for other commands that don't provide logging (things like 'chmod' && 'chown').
Again, I don't recall what C2 requires, but I wouldn't be surprised if you could get there with the tools already available.
Hope this helps. And if I'm completely off my rocker, please let me know. I'd always love to learn more.
It is nice that OpenBSD is great and wonderful. However, AFAIK, OpenBSD doesn't have C2 compliant auditing available for it either. I love people who give an answer before reading the question.
Come play Heroes of Might and Magic Mini online.
And ask them if there NT servers are C2 certified.
Using the word certified is simply wrong. That implies a certification body exists. Products are evaluated to meet the standard.
Argus Systems Group, Inc. has announced it's intent to produce a Linux version of it's PitBull compartmentalized OS. PitBull is a B1 certified, compartmentalized version of Solaris (currently Solaris 7) which I have used to much success. While all they have announced is an intent to produce a Linux version, the company moves fast enough that we might see something as soon as a year from now. This isn't exactly ideal, I understand, but in DoD time it isn't that far away.
--
Behold the Power of Cheese!
Your position is known, contemptously, as "security by assertion."
You *assert* that the intl kernel patches (which I know and use) are adequate, complete, and correctly implemented.
You *assert* that iptools2 are adequate, complete, and correctly implemented.
On and on and on. You sound just like the Microsoft commercials that are equally eloquent at *asserting* my life will be much more pleasant once I toss out my moldy old Debian 2.2 system for Windows 2000.
In fact, I've downloaded and printed out the requirements for C2 and B1 certification, and I've tried to figure out what they really mean. Linux doesn't have everything it could have (e.g., I've played with the idea of an "auditfs" that would record - in a secure manner - *all* calls to the kernel with process/user info and parameters). Linux doesn't have that, yet, but that's the only way to really know who made some sensitive calls.
But beyond the issue of auditing, DACs, MACs, secure login prompt keys, adding security classification levels to the FS (how do you make a directory top secret/categorized? Remember that the specific category is itself classified, so everyone really use large bit fields in practice.), ensuring all external media (paper, tapes, disks, discs, modems, networks, plips, IrDA, and god knows what else somebody has written a kernel module for) properly preserves these classification tags.... beyond all of that, HOW DO YOU KNOW THAT THE SOFTWARE FUNCTIONS AS ADVERTISED?
I agree with you that the assertions - plus my own review of the code when I feel the need - is adequate for my own uses. It's enough for my employers. But classified systems, by definition (hopefully), will be attacked by professional with signficant bankrolls, not bored teenagers or petty-ante criminals. They will contain information that, if misused, could result in the deaths of thousands or millions of people, not just a few annoying bogus credit card charges. The standards of proof must be *far* more strict, and there's no room for wishful thinking or unchallenged assumptions. That's why a formal review and rating is so important for the DoD (and DoE, among others) market.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Did you even look at the link? Especially where it says "The SAIC evaluation team has determined that Windows NT 4.0 with Service Pack 6a and the C2 Update as configured by the Trusted Facility Manual satisfies all the specified requirements of the criteria at class C2."
Also, when you evaluate an OS for C2, you do it on a specified set of hardware. For any OS.
FWIW, it seems worthwhile to point out that "Orange Book" classifications are not all that well thought-out. The problem is that they tie increased security to increased assurance.
It is extremely difficult to establish a high-security system while simultaneously having a high assurance that it is correctly implemented. OTOH, it is often useful to have a low-security, high-assurance system, and the Orange Book doesn't pay much attention to this case.
Indeed, if audit is the only really interesting property in this case, it sounds as though low-security (mostly logging) high-assurance (logging cannot be defeated even by 'creative' users) is exactly the solution that is needed.
In this context, I'm assuming auditing means *security* auditing. When you turn on auditing in Solaris, for example, you can log login attempts (successful and unsuccessful), file creations, modifications, and deletions, and probably any number of other things I'm unaware of.
Basically, it's a tool to help you detect breakins or suspicious behavior by users.
Any bugfixes, additions, modifications, kernel patches, etc. produced by the DoD are probably under this also. OTOH, they can justify classifying just about anything as SECRET. Because of their ability to classify, DoD is a poor test case for Linux in government.
I think that the GPL is incompatable with section 105 for a number of reasons. Of course if they just add things to the stock kernel and redistribute the mods separately, there is no problem.
Title 17 Section 105 just says that works created by the government are public domain and can not be copyrighted. That government pamphlet that you received with your census form is public domain and can not by copyrighted. You can print and give away or sell as many copies as you want.
There is no problem at all from government employees maintaining their own Linux systems. There is no problem with the government making their own customizations of the stock Linux kernel. They may not be able to distribute them outside of the government, but that's not their job. So what if the DoD classifies tham SECRET if they can't be distributed legally anyway?
Now, how is this incompatible with the GPL?
Anomalous: inconsistent with or deviating from what is usual, normal, or expected
Anomalous: deviating from what is usual, normal, or expected
Canard: a false or unfounded repor
If they need auditing, try to ask them WHAT should be audited. It would be an easy task to use PAM (= Pluggable Authentification Module) and add logging to that.
And ask them if there NT servers are C2 certified. The funny thing, against any other claim, it isn't (NT 3.5x is certified, but only if it has no disk drive and no network connection...).
If they allow NT, they should allow the use of a more secure OS (like Linux), too. Otherwise, they should remove all of their NT machines.
Really certifying for level C2 costs lots of money, and I'm afraid no one will do that for now (for what reason, anyway?).
You found a sword: +4 damage, +5 moderator points
RSBAC at www.rsbac.de
ob1 at oss.sgi.com/projects/ob1
The RSBAC works but is hard to configure. The ob1 has good docs but does not even run.
I have work on the ALPHA and PPC port.
Shaun Savage
Frankly, with the existing level of control you have in Linux, you should be able to easily walk away with a B1 for a careful installation.
I don't know what the requirements are for a B1, but I'll guess that the four components I've listed form a part of it.
I really can't see the military, for all it's paranoia, needing more extensive security than that. However, if it does, there's always Tripwire and assorted Intruder Detector packages. Not to mention firewalls, honey pots, buffer overflow detectors (or preventors), security auditing packages for ensuring that trivial holes are closed off, etc. Even the quota system offers some security capability.
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)
Check here and scroll down or search for "auditd".
**>>BELCH
hi,
. html h tml
looks like i may be one of the first to offer a useful post.
SGI is working on getting C2 grade Linux out there. they hope to have it working sometime this year. B2 will follow 18 months or so from that. Orange Linux is the project's name.
the NSA and Secure Computing are working on a C2 grade Linux as well, with source of the stuff to be made publically available due to GPL licensing.
some links:
http://biz.yahoo.com/prnews/000113/ca_secure__1
http://slashdot.org/articles/00/01/13/1029206.s
http://lwn.net/1999/1118/a/sgilinuxuniv.html
/me
jose nazario jose@biocserver.cwru.edu
Whoops, that url was goofy. Try
this one instead. Sorry.
--
Lars Kellogg-Stedman <lars@larsshack.org>
IANAL am and only familiar with this law within the context of the VRML test suite, the license of which I will now quote:
This software was developed at the National Institute of Standards and Technology by employees of the Federal Governmentin the course of their official duties. Pursuant to title 17 Section 105 of the United States Code this software is not subject to copyright protection and is in the public domain. NIST assumes no responsibility whatsoever for its use by other parties, and makes no guarantees, expressed or implied, about its quality, reliability, or any other characteristic. We would appreciate acknowledgement if the software is used.
Any bugfixes, additions, modifications, kernel patches, etc. produced by the DoD are probably under this also. OTOH, they can justify classifying just about anything as SECRET. Because of their ability to classify, DoD is a poor test case for Linux in government.
I think that the GPL is incompatable with section 105 for a number of reasons. Of course if they just add things to the stock kernel and redistribute the mods separately, there is no problem.
The real problem comes from government employees doing maintenance work on Linux.
Then what you have is the software business paying taxes so that the government can write free software and put them out of business.
They should look at BSD. It is very close to public domain. If anybody tries to touch this section of the Federal law to make an exception for Linux, I will be marching down to see my congressman so quickly to let him know that it is wrong, Wrong, WRONG!!!
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Yep, It's being replaced by the common criteria, a joint product of Europe, Canada and the US. It's just been recently standardized into an ISO. These sites should be public:
Common Criteria Project at NIST
Trusted Product Evaluation Program
Elegance is for tailors. -A. Einstein
For other interesting books in the rainbow series, see http://www.radium.ncsc.mil/tpep/li brary/rainbow/.
I'm not so sure you understand just what Mandatory Access Controls really are.
:-)
Unix traditionally has Discretionary Access Controls. I, as jruser, can grant or deny permission to other users to view my files as I see fit. If I want to "chmod o+rwx ~/.rhosts", I can do that.
Under Mandatory Access Control, however, if I don't have permission to give away a file, I can't do it, even if I want to. In other words, I may not have the right to do a "chmod o+rwx".
AFAIK, none of the features you describe enforce MAC. True, if the user doesn't have access to the network, they won't get out, but once they are granted the network connection, you have no say in what they use it for.
There is quite a bit of stuff regarding "security labels" in B1. Any storage object in the system (disk file, block of memory, etc.) gets assigned a label which describes its sensitivity and category in the organizational hierarchy. Mapping that into traditional Unix security mechanisms would be messy at best.
Possibly more importantly, once you start getting into the B levels, you find as much emphasis being placed on assurance as features. In other words, it isn't enough to say that Linux provides such-and-such, you actually have to officially prove that it does, document that proof, and find someone to sign off on it.
The Orange Book and Unix doesn't exactly line up one-to-one.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
There have been a few questions posted so far, and not a whole lot of answers, so here's my humble attempt.
(1) What is auditing?
"Auditing", in this context, is the process of keeping detailed records of system activity. This can be as simple as recording when people log in and logout, or as involved as keeping a record of every single command line run by every user.
(2) What is C2 level auditing?
The DoD defines a number of classificating that have to do with the security of a computer system. Each level has specific requirements that must be met (and, in fact, even if a system meets those requirements it still needs to be officially certified).
The C2 security level is (he said unauthoritatively) the minimum classification defined by the DoD (followed by B1, B2, B3, and A1). This defines a number of specific events (and information for each event) that must be audited.
You can find a list of auditing requirements for all the above security levels by reading
A Guide to Understand Audit in Trusted Systems, published by the National Computer Security Center.
--
Lars Kellogg-Stedman <lars@larsshack.org>
lsof: [Description] Lsof is a Unix-specific diagnostic tool. Its name stands for LiSt Open Files, and it does just that. It lists information about any files that are open by processes currently running on the system.
and
CASL [Description] Custom Auditing Scripting Language (CASL) implements a packet shell environment for the Custom Auditing Scripting Language that is the basis for the Cybercop(tm) line of products by Network Associates. The CASL environment provides an extremely high performance environment for sending and receiving any normal and/or morbid packet stream to firewalls, networking stacks and network intrusion detection systems as well as being sufficiently rich of a language to write honeypots, virtual firewalls, surfer hotel, phantom networks and jails.
Your answer is OpenBSD. I'm not sure of the certification level, but here's a quote from a recent interview with OpenBSD's project head, Theo Deraadt:
"OpenBSD is so secure that it even got the attention of the U.S. Department of Justice, which stores and transmits top-secret data using 260 copies of the OS."
The full article is here.
--Bob
I attended a Linux University workshop from SGI last Friday and at the Linux Security breakout session, the gentleman from SGI who does a lot of work with the NSA and the government said that SGI is working on making Linux C2 and B1 compliant. These should be finalized sometime next year. Auditing is one of the components that still needs to be worked on just to make Linux at least C2 compliant.
For the B1 compliancy, there has to be further security checks (like mandatory security access on the FS)
A lot of this good stuff will be coming from IRIX, which has been pretty secure in and of itself.
We should be seeing a lot of security added to Linux this year.
Fialar
The second project you may want to consider is that SGI is building an "orange book" Linux, with a goal of C2 by October, and B1 by next spring.
Note that this question was posted to Slashdot last year so you probably want to go check out the responses there.
Finally, while I'm here, I'll plug my own security-hardened Linux distro: Immunix. Immunix is not TCSEC compliant or anything like that. Rather, it is designed to be extremely difficult to break into, while preserving a high degree of Linux compatibility. Currently, it is just Red Hat hardened with StackGuard, but we will be releasing additional security technologies shortly.
Crispin
-------
CTO, WireX Communications, Inc.
Immunix: Free hardened Linux