Slashdot Mirror
UPDATED: SGI B1 Linux Patches
jd writes, "It's been rumoured for some time, but no code was shown and no announcements were made. Well, they actually did it. The first drop of the necessary code to bring Linux to B1 standards is on their Web site. The code is essentially a rip of their IRIX code, and isn't fully Linuxified, yet, but it's all there and ready." Update: 04/12 05:52 by E : We got mail from Richard, who maintains these pages... He says: "It is true that SGI are working on making Linux C2/B1 as anyone who has been to a SGI Linux University event will attest, and we are working with a number of others to that end. But to say that we have released a patch for Linux is very misleading and is setting expectations way above what is currently available." So, take this with a grain of salt.
Ian Bicking wrote:
I get the impression they can't, because the certification includes the installation.
My understanding is they could produce standalone certified system, and offer a service where they install and have certified a network sytem. It would be expensive though. I could be very wrong, since I've never been involved in such a process.
What I wonder is, what operating systems do B1-ready systems run at the present?
That's easy one to answer. According to the TPEP Evaluated Products List, the following operating systems have been used in B1-rated systems:
Amdahl UTS/MTS v2.1.5+
Computer Associates CA-ACF2 MVS v6.1 with CA-ACF2 MAC
Digital SEVMS, several versions on VAX and version 6.1 on Alpha
Digital Ultrix MLS v2.1 on VAXStation (Microvax)
Harris CX/SX v6.1.1 and v6.2.1
HP HP-UX BLS v8.04 and v9.0.9+
SGI Trusted Irix v4.0.5EPL (where this code came from)
Unisys OS1100SR1 and OS1100/2200, Several releases
You'll see that rather than making their mainstream operating system ratable, most vendors (eg. Digital, HP and SGI) offer a special version of the OS that is set up to meet the rating criterion.
----
----
Open mind, insert foot.
Irix (and Secure Irix, in this case) has some features that Linux lacks. I don't mind them on the Linux bandwagon if it means that the Free Linux kernel can get more functionality, security and scalability .
----
----
Open mind, insert foot.
Just one thing to remember, Linux itself can never be B1, or any other level certified, it's only complete evaluated systems - case, drives, os, etc. I'd not know b1+ cert well if I didn't need to know it.. thou never had to use it, gotta love government sometimes, huh? :)
bash: ispell: command not found
This sig left intentionally blank.
1) I don't know what they are off the cuff; see the article a day or two ago.
2) circular? The man doing the Trusted FreeBSD is *already* a major player in FreeBSD, making it the more natural choice for him. Code he knows inside and out, or code that's similar. Not a tough choice.
But I never said that. I made no claim as to FreeBSD being better than OpenBSD.
However, for an individual developer, the operating system he already knows and is involved with is a better *choice* unless the existing advantages to the other operating system are compelling.
Veritas can buy the IRIS version of XFS, without GPL complications, as it's encumbered and under a different licence. But if they buy the GPLed version, sure, they can charge for it, but they MUST supply the source code and they MUST NOT restrict your freedom (such as giving the source for free to everyone).
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)
Imagine being able to run all your daemons in protected spaces. So -what- if Sendmail gets cracked? It can't -touch- anything outside of it's private universe.
The same with the web server. Sure, Apache probably has problems, and many CGI scripts certainly do. But if you can't edit the web pages, grab the password files, compromise the system, or rm -fr /, getting in isn't the difficult bit. Finding anything to do, or even showing that you got there, IS.
Yeah, desktop PCs with dial-in access aren't so vulnerable. Even there, though, if you use IRC or some other easily-compromised real-time service, there -are- advantages in severely limiting the scope an attacker has. (That's why you should NEVER, EVER use something like IRC as 'root'. Most of us do, even though we know better, but whoever said sanity was a hallmark of an admin?)
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)
Hmmm.... I see a pattern here...
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)
Sorry, but this is not true at all. DEC MLS+ was based on a modified version of the base Unix kernel. Back in the early days of DEC MLS+ it was a long term goal to have B1/CMW functionality available as an installable subset that could be layered on top of the commercial unix product. It could have achieved that in the end as most of the MLS+ specific source code got merged in with the base OS source code, but just ifdef'd out so it wouldn't build into the base product.
Last I heard DEC MLS+ was being retired, with MLS+ V4.0D (or V4.0E) to be the last version. Don't take that as gospel though, plans do change.
Macka
When is SGI going to do something good for IRIX? I am a developer that uses IRIX. No other OS can give us the graphics power that we require. I use Java on IRIX and it is awful. SGI has only 3 developers working on the Java port, and has dozens working on these little Linux projects. Come on SGI, don't forget IRIX.
--Ivan, weenie NT4 user: bite me!
--weenie NT4 user: bite me!
"Computers are nothing but a perfect illusion of order" -- Iggy Pop
In case you haven't looked recently, the linux bandwagon seems to have crashed into a brick wall... Look at all the linux stock prices today vs 2 months ago... They've been beaten down far more than any other sector.
SGI's just doing what they think makes good business sense, no more, no less. They're adopting Linux as their low-end OS because it runs on commodity hardware. Many of their customers will probably buy those machines. Many of their customers also want machines with B1 ratings. They'ed probably have to violate the GPL in order to implement B1 Security into a Linux distro without releasing the source, so they're doing what's required.
Well... whether the MAC option made it into the mainline Linus tree would depend on how ugly the code was, and how much #ifdef stuff it took, I suppose.
I would imagine that it all would have to be distributed as a separate patch, though, like the real time kernel, or the 8086-80286 kernel.
But that's the point... nobody's suggesting (that I've seen) that MAC be some option you select in make xconfig. :-)
Especially since some sort of Trusted Linux would have to have a complete pre-configured installation, with each file given the proper capabilities, ACLs, labels, and such in advance.
Any MAC-enabled linux would have to be a specialised distribution, with a modified kernel, toolset, X server, window manager, shell, and everything.
It doesn't mean that the basic outline of the file system, programming interface, utilities, and everything can't be modified versions of the originals.
*chuckle*
"Better than A0 is the ultimate in security: the Heisenburg Security Rating. Here, for example, is a system rated as Heisenburg Secure. This locked box may or may not even contain a computer - and until you open it, it actually contains both! Of course, the network connections and power cables inside the box connect to the non-existent portion of the Heisenburg Secure system..."
Yes, we should care! If it's a meaningful certificate, that is. Spending millions to get a proper Unix(tm) appellation put upon Linux is not very meaningful. But getting a security certification is.
Rephrase your question thusly: "I already know how to drive, so why should I take even one hour out of my day to get a driver's license?"
If you want to drive on the B1 highway, you need a driver's license.
A Government Is a Body of People, Usually Notably Ungoverned
Orange book security don't just consider the hardware. It includes the installation, location, and all physical access and environments of the machine. These Certifications are case by case and cost a LOT.
Some time ago I went to the SGI LinuxUniversity in NYC, and they announced at their security track that they would be posting C2 and B1 patches to the kernel soon, and they expect to have 'final' versions integrated before the US goverment requirements for secure OSes kick in. I forget the exact dates, but that is the idea. btw Compaq (DEC) is working on this as well. The reason why they posted the code so soon, is that they don't want to be bashed again as they were last time when they released patches to the kernel... last time they were too late, so there was little time to review the patches, hence large chunks of code were refused (AFAIK). SGI is jumping on the linux bandwagon bigtime, but just on the x86 architecture, and the upcoming IA64. I guess they want to compete with solaris, but not with IRIX.
Actually you should always use SSH even if you're not paranoid. And personally I'd be inclined to use the md5 replacement for crypt, allowing a passphrase rather than a password to be used. There's also some PAM niftiness that allows you to use a fingerprint scanner which I should look into one of these days.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
When will it be ready for use ? Kernel 2.6 or before ? This is not a simple standalone RPM to install.
It is nice to SGI supporting linux. I guess they don't have much to do now... after selling off Cray. Besides the OpenGL wave, what does SGI do these days?
The sample codes SGI put on their web page is just a microscopic portion of a fully functional military grade OS product. It will require a complete rewrite of the whole operating system; a re-implementation of system api's, principals and concepts.
:-)
A PATCH JUST CAN'T DO THE JOB.
Let's just focus on a small but important aspect of military grade systems - PRIVILEGE. We can forget about secure networking, trusted windowing, and etc etc for now (eventually we will need to address those too).
In a trusted system, each user is held accountable for actions taken by processes being their id, even though those actions may be completely beyond perception. As a consequence, the trusted system must regulate not only user actions, but also the actions of user processes. In Linux (or traditional Unix), all power is vested in the root uid 0. Throughout the kernel of the underlying system there are checks for effective uid 0.
All of these checks are replaced on a trusted system by a check for privilege. Privileges allows the trusted system to control access to system calls, based on the requested operation and the invoking user account - much more reliable and granular than simply checking identity. No more if uid !=0 then deny access. very action which compromise security is estricted with a named privilege, and a process with appropriate privileges is allowed to invoke a system call REGARDLESS of uid.
So, on Linux a privileged operation succeeds if the effective uid == 0; on a trusted system the operation succeeds if the process has the appropriate privilege.
So now, you're probably thinking "EEK! r00t d03sn'7 0wn!'.
There are other topics such as data labelling, auditing, etc etc that I have not mentioned, but
are critical to the implementation of a trusted system and secure OS kernel.
If all those could be implemented in form of a patch, perhaps we should consider Windows 2000 a patch too.
Yours,
--Albert
In regards to the change a single thing comment.
How evaluations work under the common criteria is that you make a set of claims and the evaluator (in our case CSC), verifies those claims. This means that in theory one could certify anything.
However, just getting evaluated to meet certain requirements does not mean anything unless people know what those requirements mean. This is why under the Common Criteria there are predefined descriptions of claims that vendors can try to meet. B1 under the Common Criteria is known as the "Labeled Protection Profile". This is what we are certifying to. One part of the evaluation is what hardware and configuration you are setting up on.
This is specified under the TOE or Target of Evaluation. So yes, we are in fact being evaluated on specific equipment (you have to pick something to run your systems on for testing!). In the past you were essentially limited by what you are running on. However, because of this there has been a lot pressure to loosen up this restriction as it really does not make a lot of sense. We are in fact trying to put into our claims, a more flexible hardware claim.
Now with that said, what you have to understand is how certifications are used. In the government and military they are used as tools to help "accreditors" determine if a specific architecture meets the security requirements of the information it will be handling. B1 helps an accreditor determine that a system is sufficient. Being B1 obviously does not guarantee accreditation.
So, in reality even if you run a B1 system on different hardware or with modifications you still have a B1 system. For example, if the system you are using was evaluated with networking using a 10BaseT card, and you switch to a 100BaseT, your system is still B1. It is still functionally B1 and would still very likely be accredited by an accreditor.
If you add a piece of software to the system that is not evaluated to B1, then that software is not considered B1, but your underlying system still is. Now you can certainly do things to create an insecure B1 system, just as you can muck up permission bits on UNIX, the real strength of B1 is not in its name, in its certification, but in its functionality.
B1 systems (and I'm really referring to ours as this is the one I know the best!, though much of this applies to others) break up root powers into a least privilege system. This allows applications to only run with the specific abilities that they need to run. B1 systems use mandatory access controls that allow applications to be isolated from eachother completely. Administrative tools can be isolated, web pages can be made read-only to web servers (not based on UID, but only on security level). Finally, good B1 systems implement mandatory controls in the networking. A web admin that comes in from an internal network can be marked with a label that allows him to read/write web pages. The same user coming in from a public network (internet) can be marked with another level that will not allow them to access the pages at all.
To sum this up: Certification tells you that a vendor has created a B1 functional system, and had that fact independently verified by a highly scrutiness team of people. B1 is not about protecting "military secrets" (though it can be), but about providing security functionality that allows secure architectures to be built.
As always, I'm happy to answer more questions.
If anyone can give me insite on doing an interview, I'd really like to talk about how people can use B1 systems to solve real security problems (not military problems).
Cheers,
Jeff
Jeff Thompson
Software Evangelist and Visionary
Argus Systems Group, Inc.
It's been answered before, too :)
1) not quite the same type of security issues.
2) more importantly, it's from a major contributor to FreeBSD.
Then, of course, you could use OpenBSD's FTP daemon, and Postfix as a drop-in Sendmail, and you'd have a very tidy setup.
For the uber-paranoid, pipe -ALL- IPv4 and IPv6 traffic via IPSec or SKIP, use SSH rather than Telnet or RSH, use CBQ/RED and SYN cookies to prevent DoS attacks, use client-side certificates for private web-pages, use the shadow password suite + PAM, install the International Kernel Patches and encrypt all but your boot partition using Serpent, install the re-freed Tripwire (or a clone), and use the Linux Kernel capabilities to disable all non-essential functions.
Personally, I think using the SGI's B1 patches, plus the above configuration, would give you a setup which would be as close to uncrackable as you could realistically get AND still give access to outside individuals.
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 been a while since I looked at the B1 definitions, but let me see if I describe MACs as I understand them.
The key aspect appears to be a distinction with Discretionary Access Controls (DAC) - owner and group permissions, ACL lists, etc. DACs are controlled by the owner of the file, but MACs are controlled by the "security administrator." The terms "mandatory" and "discretionary" reflect the fact that the owner must always accept MAC access control on his files, but he can discard the DAC checks (e.g., using mode 0777).
One of the subtle points about MACs is that they are required to be persistent *in all media*. This means that MACs should be preserved (and enforced) when a file is copied to removable media, and somehow indicated on all printed pages. (E.g., printing the "sensitivity level" (confidential, secret, etc) in large type on all printed pages.) Obviously you can't preserve MAC information if the format doesn't support it, so a MAC system may be able to write (enhanced) tar images to tape, but not be able to copy files to a floppy/zip/etc disk using MSDOS or even ext2fs filesystems.
There may be more to MACs; the specs are deliberately vague. A *very* large part of the certification process is going through the appropriate standard and documenting *what* you did and *why* you did it, with some commentary about the implications of that decision. This provides the implementer the flexibility of using whatever technique fits their needs. E.g., nothing says that DACs must be implemented with ACLs, although most people now use them because they're familiar and proven acceptable to the certification agencies.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Media can be of 2 types -- multi-level or single-level. A Multi-level media supports inclusion of MAC labels. Single:not. You simply define the Sensitivity and Integrity level of the mounted tape drive (or FAT, FAT32, normal NFS, etc).
/etc/passwd unless they specifically log in with S=2 or su to S=2 (requires password again).
/etc/shadow was set to 2. Say users run at S=0. Root is permitted to run at S=2 (say highest) and S=0 (lowest). Implications:
/etc/shadow, root must relogin or su to get S=2. 'Su' to a different integrity or sensitivity level must recheck password and if the user is allowed to run at the requested levels. After root has S=2 can then read /etc/shadow in order to 'modify' it (they have to also have raised their Integrity to '2' to write to it).
/etc/shadow because of MAC policy regardless if someone get's sloppy with DAC bits.
Modeling under the Bell-LaPadula Sensitivity and Biba Integrity models (one type of MAC often used), we have a couple of rules and two groups of items: "Subjects" - things that access or do things and "Objects" things that are accessed or done to. Some things in a system can fall into both contexts depending on the situation. For example, a Subject "Process" (they do things to
objects like files) could also access another process -- the accessed process would be an 'object' as far as security checks are concerned.
So Rule 1) Subjects (S) can only write to an Object (O) if the Object is at the same sensitivity level or above (O is said to "dominate" the level of S and dominate implies >-).
Rule 2) says that Subjects can only read Objects that they dominate (their sensitivity level is >= to the object's).
Biba Integrity works the same but opposite:
Rule 3) Subject can only write to Objects if Subject's Integrity >= (dominates) the Object's.
and Rule 4) Subject can only read Objects that have equivalent or greater Integrity (integ(O)>=integ(S)).
This can be *way* useful for "normal users".
Think of this:
Root is allowed Integrity levels 0-2, default=1. All system files at integrity level 2 (both executables and data). Users and their files are set at integrity level 0. Implications:
1) Any file root creates has I=1 so normal users can't write to it unless the file is specifically downgraded. A subject can write to or create "downgraded" Integrity files, so root is permitted to write lower level integrity files, but this wouldn't be the default creation value. Even if root downgrades the file's Int., Discretionary Access Control (DAC) (i.e. permission bits) still apply.
2) Root can't write to
3) Users could read these 'public' files but couldn't write to them even if the file DAC was 0777.
3) Root couldn't execute any files not in the 'system file list'. No trojans! Only if root overrides security policy and changes the state of a file to 'trusted' (@ int=1 or 2) can it be executed as root.
Now for Sensitivity, let's imagine
In order to modify
So normal users can't see
Just these "simple" applications of MAC would not greatly inconvenience any user, but an attacker gaining root (unless they do so via the password) has limited power. This means most attacks that gain 'root-shell' via a 'bug' are still pretty limited in what they can do.
Now if you add file based capabilities, root can have even less priviledge and/or ability to do damage.
Also, remember, as I've mentioned before -- if you set MAC,S=0,I=0 for everything in the system, you get traditional Unix DAC behavior.
-l
I am interested in when for example the various distros will impliment this. I already have taken the first step. Namely not having an internet connection as most humans know it. So exactly what is out there. A while ago Trusted BSD came out. I would really like to get my machine to a B1 raiting so perhaps I can get bragging rights for something.
Will this ever happen?
Slashdot social engineering at it's finest
"you turd, think about it. Linux may get certified, but that will be only one specific distribution. Since all "linuxes" are different, they can't all have the same security rating. "
Actually I think anything about C1 has to get evaluated on a case by case basis by a certified DoD contractor. So even if you think you have a secure OS you may in fact not.
Slashdot social engineering at it's finest
Okay, I think I understood the nutrient patch article earlier today. But B1 patches? Does it help them avoid refueling, or just replenish the supply of bombs?
Take a look at the requirements for B1 listed above. There's no way to support MAC, ACL, etc. with the standard Unix model. You can't just layer these things on top of the kernel without inheriting the flaws of the kernel.
There have been quite a few "secure unix" systems produced and B1 certified. HP, Concurent, Harris, DEC all come to mind. But in all of these cases they started with a secure kernel and then layered Posix on top of it to make it look like Unix.
So what? So, you can't PATCH the Linux kernel to make it B1. Unless you call "throwing out the kernel and replaceing it with a totally different beast" a patch.
BTW, if you really want an A1 operating system to play with, there is a free one - mentioned on /. - at:
http://www.eros-os.org/
It hasn't been certified yet, but the pieces are there.
Most techs still make a choice based on facts and real-life requirements and experience instead of some certification. We like to do it ourselves, no?
These improvements *will* improve Linux. That's all that matters. Any certifications that might be the result of it are merely a side effect and not very important, to us.
Beefing up Linux to C2 will be a great thing for commercial interest/acceptance, and only small changes to existing GUI interfaces would be needed to accomodate that (adding ACL options to widgets that display/manipulate file permissions).
B1 however is a different kettle of fish. GUI's like KDE, GNOME, and others would have to be extensively modified to work properly (if at all) in a B1 environment. The standard for this is called CMW (Compartmented Mode Workstation). Commercial products like DEC MLS+ are implementations of B1/CMW on top of the standard Unix product. I don't know what SUN's is called, but they do the same.
This also applies to almost anything else that is not part of the kernel, eg:
* TSIX instead of TCP/IP, which automaticly excludes you from participating in non B1 DNS environments, and allows you to configure networks restricting communication between systems of the same SL (Security Level) or perhaps SL's that yours dominates (with the appropriate kernel privs enabled).
* A new filesystem, or extensions to an existing filesystem, to make it multilevel aware. That way, when you cd(1) into a directory that contains files that have a higher SL than you have Clearance to access, you don't see them. Not from an ls(1) or by any other C hackery you can conjure up, because they are blocked at the filesystem level.
* A new multilevel print environment, so that for example files with an SL of "Top Secret" cannot be printed out on printers that don't have the same or higher SL (eg, Secret, Confidential, Unclassified, or whatever they have been called in the environment you're in).
* Getting back to CMW again. On a B1/CMW workstation where the GUI is multilevel aware, if you have logged in selecting an SL of "Secret" (assuming you have Clearance for this) and you open a terminal window with that SL, then open another terminal window with a lower SL, eg "Unclassified" then you will NOT be able to cut and paste text from the Secret window to the Unclassified window (unless you have privs allowing you to override this AND they are turned on). GUI's that are not multi-level aware (like all the ones that currently exist) would only be able to work as they stand on one SL at a time. If you wanted to work with files (or viewable data) at a higher SL than the one you were logged in on, you'd have to log right out and log in again at the higher SL.
Working with B1 and CMW can be very complicated. Designing and setting up an environment that has all these features is even worse. Which is probably why B1 has never caught on in the commercial world. Applications not specificly written or modified to run in a multi-level environment, can only operate on one level at a time (ie: the level they are start at) which often defeats the object of having a multilevel enviromnent in the first place.
Maybe Linux could shine here though. Last I heard (maybe it's changed again
Macka
TrustedBSD "provides a set of trusted operating system extensions to the FreeBSD operating system, targeting the Orange Book B1 evaluation criteria"
And they also have a mondo-cool logo.
Returned Peace Corps IT Volunteer
Actually, there's an even more secure rating than A1.
A0, as defined by the military, is an unplugged, completely disassembled computer system where all volatile magnetic memory has been exposed to extremely powerful electromagnets for at least 72 hours. Each piece is then separately taken Cape Canaveral via several different types of transportation (horse, plane, submarine, postal carrier), launch into orbit (using Space Shuttle flights randomly chosen from a calendar) whereupon they are loaded into small, disposable rockets and fired towards the sun along with all documentation.
Just to be fair, they recently obtained a C2 on NT4+special service pack+certain hardware, in a networking environment. See here for more info.
The scale works like this: there are different security levels, each with stronger requirements. The actual requirements are quite numerous, here's a long article with details.
The illegal we do immediately. The unconstitutional takes a little longer.
--Henry Kissinger
--
-- Slashdot sucks.
Orange Book certification (C2, B1, etc.) usually requires certification of a total system... not just the operating system. So, even if you could install all their mods in a single package, you would need to certify the OS along with your brand of PC, controllers, etc.
Be that as it may, it is a great start.
Security levels C2 and greater (including B1) will be useful for getting Linux into government offices, the same ones where NT is C2 certified (as long as there is no network connection [smile!])... the government already has a large installed base of desktop systems.
Linux's low cost of entry and now B1 features is just more of the foot in the door for the government and other people that will have to take a look at this system that was once dismissed as a "toy" by others.
--
"May I have ten thousand marbles, please?"
Here's a whirlwind tour of the Orange Book categories.
D level systems have no security worth mentioning. Think DOS, Win95, MacOS - no real notion of separate users.
C level systems have DAC - discretionary access control. Essentially, they have ACLs (access control lists). You can determine who can have access to your stuff. There are two divisions here, C1 and C2, with C2 being more stringent.
Several Unix-type systems have been certified at C2 (though you have to add ACLs), as has WinNT.
B level systems add MAC - mandatory access control. Every object (file, device) and subject (process) has a level (often something like unclassified, secret, top_secret) and a set of categories associated with it. If you're cleared for "secret/stealth_bomber, SDI, Area_51", you can't read stuff labeled "top_secret/who_killed_JFK" or "secret/Clintons_little_black_book". And you can't write something "unclassified/Area_51", so you can't spill the beans. (But you can write to objects at a higher level than you are.) There's B1, B2, and B3. I think you can still count the number of certified B-level operating systems on your fingers.
A1 level systems have been mathematically proven. IIRC there's only one that's ever been certified at this level.
There's also something called CMW (compartmented mode workstation), which is like the B levels but deals with "information labels" instead of "sensitivity labels" - i.e., it tries to track what's really in the object, so if you paste secret data into a file it gets upgraded.
It's a bitch to get something certified (I worked on Trusted Mach, which was intended to be B3 but never went anywhere); we're talking piles of documentation, many rounds of review, and a pile of money.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood