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

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.