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.

Comments

Re:Good first step

[Gleef]

True, Linux can never be B1 (or any level) certified itself (neither can NT be C2 certified, contrary to Microsoft's marketing). It can, however be B1 ready, with all the features needed to produce a B1-rated system. Then, VA Linux Systems or Penguin Computing can produce and sell a truly B1 (or C1, for that matter) certified system. That would be a very nice thing to happen.

As for A1, I don't think any modern operating system can reach that level. The proof requirements for A1 certification would be prohibitively expensive for anything but the most scaled down system.

----

why Trusted FreeBSD rather than open

[hawk]

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.

Re:Go SGI

[jd]

I dunno. Remember, mandatory access controls mean that compromising a daemon does NOT give you access to anything outside the scope of that daemon. Nor does read permission mean write permission or chmod permission. Nor can you chown or otherwise give access to a file to someone who has lower clearance.

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.

Re: Mandatory access control

[coyote-san]

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.

Re: Mandatory access control

[LindaAthena]

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

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 /etc/passwd unless they specifically log in with S=2 or su to S=2 (requires password again).

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 /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:

In order to modify /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).

So normal users can't see /etc/shadow because of MAC policy regardless if someone get's sloppy with DAC bits.

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

A good security question?

[slashdot-terminal]

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?

Re:Go SGI

[slashdot-terminal]

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

More patches?

[billh]

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?

Unix can't do B1

[Anonymous Coward]

Sorry, but I have to remain an AC on this one, for obvious reasons.

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.

Certification? Oh No!

[Rob Kaper]

Having a certification might impress some suits, but do *we* really care?

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.

What about CMW

[Macka]

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 :-) DEC MLS+ from Compaq was being wound down. What killed it was the lack of applications that could run on it properly because they needed significant re-engineering to be multilevel aware (read huge cost!). Because the source of most linux apps are open, this would not be such a huge barrier to overcome. It will be interesting to wait and see.

Macka

FreeBSD to have similar plugins

[griffjon]

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.

Re:I prefer A1

[Shadowlion]

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.

Re:B1??

[ianezz]

since they have it only if NT is not networked.

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.

Re:B1??

[-brazil-]

The scale comes from something known as the "Orange Book", and yes, "C2" also comes from there, and if M$ claims they got C2, they're full of shit (as if that were new...), since they have it only if NT is not networked.

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.

For a summary...

[Amphigory]

Bear in mind what these things mean. From the "TCSSEC" FAQ:

18. What are the requirements for a D/C1/C2/B1/B2/B3/A1 system?

The Interpreted Trusted Computer System Evaluation Criteria (ITCSEC) available in postscript at contains the definitive set of requirements for each TCSEC class. In Summary:

Class D: Minimal Protection

Class D is reserved for those systems that have been evaluated but that fail to meet the requirements for a higher evaluation class.

Class C1: Discretionary Security Protection

The Trusted Computing Base (TCB) of a class C1 system nominally satisfies the discretionary security requirements by providing separation of users and data. It incorporates some form of credible controls capable of enforcing access limitations on an individual basis, i.e., ostensibly suitable for allowing users to be able to protect project or private information and to keep other users from accidentally reading or destroying their data. The class C1 environment is expected to be one of cooperating users processing data at the same level of sensitivity.

Class C2: Controlled Access Protection

Systems in this class enforce a more finely grained discretionary access control than C1 systems, making users individually accountable for their actions through login procedures, auditing of security-relevant events, and resource isolation.

Class B1: Labeled Security Protection

Class B1 systems require all the features required for class C2. In addition, an informal statement of the security policy model, data labeling (e.g., secret or proprietary), and mandatory access control over named subjects and objects must be present. The capability must exist for accurately labeling exported information.

Class B2: Structured Protection

In class B2 systems, the TCB is based on a clearly defined and documented formal security policy model that requires the discretionary and mandatory access control enforcement found in class B1 systems be extended to all subjects and objects in the automated data processing system. In addition, covert channels are addressed. The TCB must be carefully structured into protection-critical and non- protection-critical elements. The TCB interface is well-defined and the TCB design and implementation enable it to be subjected to more thorough testing and more complete review. Authentication mechanisms are strengthened, trusted facility management is provided in the form of support for system administrator and operator functions, and stringent configuration management controls are imposed. The system is relatively resistant to penetration.

Class B3: Security Domains

The class B3 TCB must satisfy the reference monitor requirements that it mediate all accesses of subjects to objects, be tamperproof, and be small enough to be subjected to analysis and tests. To this end, the TCB is structured to exclude code not essential to security policy enforcement, with significant system engineering during TCB design and implementation directed toward minimizing its complexity. A security administrator is supported, audit mechanisms are expanded to signal security-relevant events, and system recovery procedures are required. The system is highly resistant to penetration.

Class A1: Verified Design

Systems in class A1 are functionally equivalent to those in class B3 in that no additional architectural features or policy requirements are added. The distinguishing feature of systems in this class is the analysis derived from formal design specification and verification techniques and the resulting high degree of assurance that the TCB is correctly implemented. This assurance is developmental in nature, starting with a formal model of the security policy and a formal top-level specification (FTLS) of the design. An FTLS is a top level specification of the system written in a formal mathematical language to allow theorems (showing the coorespondence of the system specification to its formal requirements) to be hypothesized and formally proven. In keeping with the extensive design and development analysis of the TCB required of systems in class A1, more stringent configuration management is required and procedures are established for securely distributing the system to sites. A system security administrator is supported.

Enjoy.

--

B1 Summary

[Plutor]

B1 Security - "Labelled Security Protection"

• Object protection can be on a single-user basis, e.g. through an ACL or Trustee database.
• Authorisation for access may only be assigned by authorised users.
• Object reuse protection (i.e. to avoid reallocation of secure deleted objects).
• Mandatory identification and authorisation procedures for users, e.g. Username/Password.
• Full auditing of security events (i.e. date/time, event, user, success/failure, terminal ID)
• Protected system mode of operation.
• Added protection for authorisation and audit data.
• Mandatory security and access labelling of all objects, e.g. files, processes, devices etc.
• Label integrity checking (e.g. maintenance of sssensitiy labels when data is exported).
• Auditing of labelled objects.
• Mandatory access control for all operations.
• Ability to specify security level printed on human-readable output (e.g. printers).
• Ability to specify security level on any machine-readable output.
• Username and Password protection and secure authorisations database (ADB).
• Protected operating system and system operations mode.
• Periodic integrity checking of TCB.
• Tested security mechanisms with no obvious bypasses.
• Documentation for User Security, Systems Administration Security, Security Testing, examining audit information, and TCB design.

Of course...

[lar3ry]

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

Re:B1??

[Mr. Slippery]

It's a little more complicated than that...

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.