Slashdot Mirror

It helps to have a link with the suggestion someone go read something.

Linux 2.6 has 6 million lines of code. Even assuming a linear increase (in reality it is exponential) it would take at least 600 years on the current hardware. If the time demands are exponential, you can forget it altogether

Windows NT 3.5, Service Pack 3, running on one of three specific PC configurations with no external communications (and no floppy drive, as I recall), reached C2 certification. NT 4.0 managed to get C2 certified running at Service Pack 6a with a special C2 update, again only on certain configurations. 3.51 was never certified at all. To the best of my knowledge, no Microsoft OS ever achieved or even began the process for B2 certification.

If you want more details, look at the C2 evaluation reports.

> The author is completely wrong when he says that Windows did not have any security until 2000. Windows NT was designed
> from the outset to obtain Orange book B2 certification. It would take a huge amount of work to get Linux to meet that
> criteria. It is generally considered to be 'B2 equivalent' but thats like saying that being ABD is the same thing as
> having a Phd, the only people who say that are ABD grad students.

Actually it was C2 security then: http://www.radium.ncsc.mil/tpep/epl/entries/TTAP-C SC-EPL-99-001.html
A level of assurance basically every UNIX or UNIX like operating system had at that point - whether officially certified or not. It's really not that hard to have C2 certifiable security. OTOH all commercially available B2 certified Operating Systems were to my knowledge UNIX based.

Do I expect too much to think that slashdotters could back their arguments up with actual information? Sigh.

MS claims that they're only susceptible to viruses because they're popular. Is this true, or are there just more security holes at a fundamental level?

Don't you think we should look at the actual design differences between Windows and UNIX? Here are some, off the top of my head...

1. UNIX has granular, file-level permissions. Does Windows have this? When renegade malware claims access to a box, how much damage can it really do to a UNIX system versus a MS system?

2. Processes in UNIX run in protected memory space. It takes great effort to transgress the assigned process image locations in UNIX and access memory space that is not allocated to that particular process. Does Windows have this protection? I don't think so. I could be wrong (I don't program in windows-land), but if anyone could substantiate this, maybe we could find our answers.

3. Buffer overflows are rampant on Windows. They're rampant on lots of OSes, but they seem to be consistently endemic to anything Microsoft writes. Is this because the APIs for Windows used to be written in C++ (I'm thinking MFC, not .NET), where buffer overflows are a given part of the fun?

3b. Again---when this occurs on UNIX, it doesn't generally open up the system to attacks. But in Windows, an application that fails opens up everything to attack.

4. Oh, let's not forget the rest of C++ based fun: dangling references, memory leaks, etc.

5. System calls just seem up for grabs on Windows, am I right? In UNIXland, you can't say fsck without filling out things in triplicate.

6. The test of time. Core system design in UNIX has been reviewed, revised and rewritten by competing parties for DECADES. Who knows what goes on in that Redmond ivory tower.

Maybe the Orange Book goes into more detail than I have time for.
http://www.radium.ncsc.mil/tpep/epl/index.html

Anecdotally, however, I can tell you that I've never had to restart my BSD system, nor my HP/UX system. But as for Windows, I can now press Ctrl-Alt-Delete without even looking.

BTW-- What does hard drive failure have to do with an OS? That's hardware.

Its cold in here. Somebody fan me some flames.

That's a pretty big statement. There are mainframe OS'es used in banks and the like that have not been rebooted in a decade+ - how has it been determined that OS X is that stable?

Secure? People involved in things like OpenBSD and VMS might be surprised to read such a thing. Let alone Wang's XTS-300 STOP (http://www.radium.ncsc.mil/tpep/epl/epl-by-class. html) or many many other operating systems. But hey, don't let a blanket statement be ruined by little things like that.

Vendors hated this process. First, the vendors didn't control the test process - the National Security Agency's Central Security Service did. NSA's policy back then was that you got two tries to pass validation. On the first try, the vendor was told of problems found, and given a chance to fix them. The second try was strictly pass/fail, and might include tests that the vendor had never seen. So it was quite possible, and common, for products to flunk and be cut out of procurements.

The Common Criteria process, on the other, hand, is conducted by third party labs paid by the vendor. So they're very "responsive" to the vendor.

The "Common Criteria" are comparable to the class C Orange Book standards. They're very weak. There was heavy lobbying by the computer industry to water down the Orange Book standards, and that lobbying was successful.

The evaluation report for Windows XP is online. It's worth reading, even though it's long.

Vendors hated this process. First, the vendors didn't control the test process - the National Security Agency's Central Security Service did. NSA's policy back then was that you got two tries to pass validation. On the first try, the vendor was told of problems found, and given a chance to fix them. The second try was strictly pass/fail, and might include tests that the vendor had never seen. So it was quite possible, and common, for products to flunk and be cut out of procurements.

The Common Criteria process, on the other, hand, is conducted by third party labs paid by the vendor. So they're very "responsive" to the vendor.

The "Common Criteria" are comparable to the class C Orange Book standards. They're very weak. There was heavy lobbying by the computer industry to water down the Orange Book standards, and that lobbying was successful.

The evaluation report for Windows XP is online. It's worth reading, even though it's long.

Which can be found in the NCSC Rainbow Series Library along with most of the other books in that very neat picture.

it wasn't "Windows NT" that got the rating (as much as M$ hyped it, and I don't remeber the exact spec, but the spec gave the EXACT make and model of computer (and hence hardware spec (that didn't include a network card)) as well as the exact patch level of NT and it specified the applications installed.

Of course -- in fact, that's the case with any such certifications. They never certify an OS as being secure -- they only ever examine and certify a specific installation, and any modification to that installation requires re-examination and re-certification.

In short it wasn't generically Windows NT, or even Windows NT4 sp2.

Just in case it wasn't clear the first time, I'll repeat: it is never generically any operating system, or other component. A certification is only ever given to a specific installation. After that's been done, most of the components that were used in that installation are placed on a certified products list. This basically helps others by letting them know that there is a configuration in which this product has been certified, so if (for example) that configuration fits their needs as well, getting their own installation certified is likely to be considerably easier than if they use an otherwise similar component.

The statements I saw from MS at the time claimed that Windows NT had been placed on the "Evaluated Products List", which was absolutely correct. That's not the same as claiming that NT in general had been certified.

Here is what MS has to say on the subject (I'm not sure, but one-time registration may well be needed to view that). Note in particular that far from claiming that the OS in general was certified, they specifically point out (as I did above) that an OS is never certified, but that the OS was placed on the Evaluated Products List. While this page mentions a certification of NT 3.5 (and a similar certification of NT 3.51 in the UK) they don't mention a certification (also at the C2 level) of WIndows NT 4.0 Server.

Anybody who cares can look at the entire Evaluated Products List.

--
The universe is a figment of its own imagination.

Basic government security levels:
1.) For Official Use Only (not important, really)
2.) Classified (usually sensitive technical data)
3.) Secret (much more sensitive technical or operational data)
4.) Top Secret (stuff like nuclear weapons handling procedures, etc.)
5.) Top Secret Compartmented, and up (who *did* kill Kennedy? These guys know.)
Not that it's really important, but to avoid sounding like a n00b, "classified" is different from "secret".

Also, if you want to know more about what the DoD considers a trusted computer system, look here. If you can manage to stay awake through the entire document you win a prize.

The Rainbow Series was a series of books published by the government on developing and deploying secure computing platforms in the late 80s, in conjunction with the DoD and MITRE. It's now largely dated, but there's still some good theory to be found. It's also freakin huge, and would take years to read them all.

If your OS can execute a program to let you do your finances, it can execute a program to then send that data somewhere.

Why should your os allow access to financial files to a program that it allows it to send anything anywhere but your bank as identified and certified by a trusted third party?

So how do you write software which is usable by humans, but not usable by worms?

Thats what people asked themselfs when working on openvms and multics, its what they wondered about after the morris worm. The people who found answers where not obducted by aliens after they did! They where just ignored for a decade, which may be even worse... well for the rest of the world anyway.

Most of the answers are right in the orange book. Another answer is not to use a language/platform that allows for buffer overflows when doing something mundane.

I am not saying these ideas are perfect, I am saying they are almost thirty years old but not advertised at compusa! They are currently being "reinvented" very very slowly. AMD offers memory that is hard to run instructions from, microsoft started adding bufferoverflow fighting tricks to its compiler and from time to time compiles some of its producs with it. Unix alikes have trouble deciding their aproach but there is progress. Also the linux kernel has room for setting files to something more subtle then 666. Java has a somewhat complete reference monitor... but ofcourse noone uses it becouse an application taking a little more time to start up takes more time then cleaning out an internet explorer abusing piece of malware... Microsoft for the first time ever sacrifices backwards compatability for security in servicepack 2 and what do people do? They whine about it..

people should start trying to make secure systems useable again instead of just making them insecure. The first step? explaining everyone that current insecurity is the couse of much lost time and will cost much more money then a bit of DDoS here, mixed with ID theft and the occasional bank heist using a keylogger.

Quite possibly the most secure kernel ever built and absolutely not vulnerable to buffer overflow attacks. Uses all the x86 security features, segmentation, multiple privilege levels and enforces MAC secrecy and integrity policies:

http://www.radium.ncsc.mil/tpep/epl/entries/CSC-EP L-94-008.html

Are you saying this has been done? Multics had better buffer overflow protection

40 F#%îng years ago! thats right, *before unix existed*, four decades ago, thats before gates had pubic hair! (Okey, I didn`t fact check that one, but this is a long time, and I am not just talking in Internet or doggy years.)

So, where are the lines before compusa to buy one of these computers that may not have the most megahurts and marchitecture, but that doesn`t get new viruses/spyware/script kiddy zombie code every week while mailing personal files to random strangers?

I will tell you where these people are, they are right around the corner at the newsstand waiting for the latest issue of "screenshots, colors, windows and screensavers monthly". While there are billion dollar (memory) price fixing and (os) monopoly scams going on the trade media wonders what the color of Microsoft's next operating system is and where to get the newest megahurts this month....

The reason multics was secure, the people designing it figured security would make a nice feature so the designed it in by default... Ofcourse others tried that but once you add a huge piece of shell/browser/e-mail client/media player, mix in a bunch of rpc accesible administrative tools and have all this code monkey C code run with administrative privileges.... then you are gonna need systems to tell you when your remaining security is gone. (virus signature addiction systems, packet filters and intrusion detection systems).

The babysteps taken in todays "security addons" that descent from the tools dos admins used to clean out the few know viruses are pathetic. The worst part, the people making money of it. These people are evil even by atheist standards (keeping people addicted to virus signatures while selling telephone tapping equipment by comverse/the mossad, while playing "trusted" third party by selling expensive cert`s (Want a microsoft.com one? here go right ahead).... while screwing everyones DNS over just for a few quick bucks. )

The people selling computer security are snakeoil/ducttape sales scumbags

If people had just read the US DoD stuff on computer security (multics, orange book) and used it as a starting point for a one step more secure OS we could just worry about how to make computer do new usefull stuff instead of fending of the spyware/worms/ddos and god knows what people who stay out of log files do. Anyway, one can always start from scratch

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

...the Registry was and is a big hole, but as a peer-poster says, "big dobs of stupid". Lots of compromise architecting to make WOW work, etc.

VMS was (is) able to be secured to genuine high military levels with one configuration change. NT and children, with much work, can be certifiably secured only at the lowest levels and with ridiculous hardware configurations. The details in between are arguable, the results are not.

The hosting hardware for the Windows NT platform in the evaluated configuration includes single processor and multiprocessor versions of the Compaq Proliant Server models 6500 and 7000, and Compaq Professional Workstation models 5100 and 8000. It also includes a HP DAT SCSI tape drive and HP Laser Jet PCL5 printers. A networked configuration was evaluated for interconnecting the various hardware with Windows NT workstations and servers.

The wonder technology was not Microsoft's; their contribution was to ship it, including embedded, with a *NULL* administrator password and to leave FoxPro to whither on the vine.

In each case, Microsoft took a good technology and tried to make it suck, with varying degrees of success.

...the Registry was and is a big hole, but as a peer-poster says, "big dobs of stupid". Lots of compromise architecting to make WOW work, etc.

VMS was (is) able to be secured to genuine high military levels with one configuration change. NT and children, with much work, can be certifiably secured only at the lowest levels and with ridiculous hardware configurations. The details in between are arguable, the results are not.

The hosting hardware for the Windows NT platform in the evaluated configuration includes single processor and multiprocessor versions of the Compaq Proliant Server models 6500 and 7000, and Compaq Professional Workstation models 5100 and 8000. It also includes a HP DAT SCSI tape drive and HP Laser Jet PCL5 printers. A networked configuration was evaluated for interconnecting the various hardware with Windows NT workstations and servers.

The wonder technology was not Microsoft's; their contribution was to ship it, including embedded, with a *NULL* administrator password and to leave FoxPro to whither on the vine.

In each case, Microsoft took a good technology and tried to make it suck, with varying degrees of success.

...the Registry was and is a big hole, but as a peer-poster says, "big dobs of stupid". Lots of compromise architecting to make WOW work, etc.

VMS was (is) able to be secured to genuine high military levels with one configuration change. NT and children, with much work, can be certifiably secured only at the lowest levels and with ridiculous hardware configurations. The details in between are arguable, the results are not.

The hosting hardware for the Windows NT platform in the evaluated configuration includes single processor and multiprocessor versions of the Compaq Proliant Server models 6500 and 7000, and Compaq Professional Workstation models 5100 and 8000. It also includes a HP DAT SCSI tape drive and HP Laser Jet PCL5 printers. A networked configuration was evaluated for interconnecting the various hardware with Windows NT workstations and servers.

The wonder technology was not Microsoft's; their contribution was to ship it, including embedded, with a *NULL* administrator password and to leave FoxPro to whither on the vine.

In each case, Microsoft took a good technology and tried to make it suck, with varying degrees of success.

When I learned my way around Unix systems, Unices were server-only operating systems (pre-Linux era). And I was taught that there isn't a one-size-fits-all solution; some applications require a high-security setup (like Multics was at the time) and some just don't.

The problem with that is that you actually have to think when using a system. You can't just assume that things on system X are the same as on system Y. That's why I learned to use vi (heck, I once had to fix a system that had no text editor to speak of -- echo works wonders in those cases). That's also why I was taught to stick to certain principles.

Multics, for instance, had a pretty good ACL implementation (for a broad overview, check out this link). Most Unices, didn't (and many still don't).

Even on those boxes that did not have any ACLs, I would still act as if they were in place. One rule that makes life a whole lot easier (not just from a security but also from an accountability standpoint) is that each and every application should only user their own space. That's why every app I use has its own data directory (and tmp directory, if possible).

It's really nothing more than an old habit. There's no particular reason I'm sticking with it (except that it works). Sort of like gun enthusiasts pretend that a firearm is loaded even when they've verified that it's not. It's basically like the safety on a gun - it's another layer of security.

I think I can answer that with an unqualified "no".

show me the most secure windows, I'll show you 10 more oses more secure than that.

Windows Unplugged(tm). For extra security, Windows in a Concrete Box at the Bottom of the Ocean(tm). This exciting new OS, to be released after Longhorn, is in the process of getting its A1 security rating.

One can name over a dozen OSes that garnered the famed Class B1 Trusted OSes status that provided this feature set since 1983. Most of them will never see the light of days due to their classified status.

Perhaps, the U.S. Patent Office should consider investigating for possible industrial payola to their underpaid $60,000/yr GS-5 ranking corporate-rejecting $125K real bad diploma-milled reviewers.

5. Setting a Low Bar

An important part of the CC is the Protection Profile, a standardized statement of requirements for what a given kind of product should do. In many cases, these standardized documents set a low bar for security. Windows 2000, for example, was certified against the Common Access Protection Profile[3], which

... provides for a level of protection, which is appropriate for an assumed non-hostile, and well-managed user community requiring protection against threats of inadvertent or casual attempts to breach the system security. The profile is not intended to be applicable to circumstances in which protection is required against determined attempts by hostile and well-funded attackers to breach system security. The CAPP does not fully address the threats posed by malicious system development or administrative personnel.

Jonathan Shapiro at Johns Hopkins has done a great job of translating that into colloquial English[4]:

Don't hook this to the Internet, don't run email, don't install software unless you can 100% trust the developer, and if anybody who works for you turns out to be out to get you, you are toast.

In the real world, Windows 2000 systems require protections beyond the low bar set by the CAPP. Nonetheless, defense buyers are free to purchase and deploy off-the-shelf Windows boxes: They simply check the box marked "EAL4". Checkbox security is fraught with risk.

To make any sense of the various Evaluation Assurance Levels (EAL) you need to understand what the Common Criteria is, where it came from (US military InfoSec), and what it is trying to do - a standard for purchasing and implmenting military and government computer systems for classified or sensitive data. You also need the other half of the equation, the Protection Profile, what it is trying to achieve. There is a far greater focus on access control, and auditing than in your typically commercial computing setting. It is about assurance, not security.

The EAL has become a media sound bite, it is quick and easy to mention in 30 seconds, but does not tell you much on its own.

So you really need two bits of information, the Evaluation Assurance Level, 3+ in this case, which implies that they producted a lot of documentation about how SuSE Linux Enterprise Server version 8 with Service Pack 3 on IBM eServers (entire line from x86 and PowerPC series to zSeries mainframes) and in the end it meets the Controlled Access Protection Profile.

Common Criteria does not focus on failure, or how things breaks, but looks at how things are designed to operate. It does NOT look for implementation flaws in most EAL levels actually acheived.

If you do any reading on Common Criteria (CC) you will quickly realise that it has little to do with secure computing, but more with assurance that if you use a given certified system you will not be blamed for any security breaches because you choose the supposely correctly labelled systems.

If CC was more popular, maybe more software programmers would focus on good software design, because their designs have to be documented, and at high enough level, they must be independently reviewed. Good design, as well as using the available resources to eliminate classes of flaws would reduce security risks by several orders of magnitude.

To make any sense of the various Evaluation Assurance Levels (EAL) you need to understand what the Common Criteria is, where it came from (US military InfoSec), and what it is trying to do - a standard for purchasing and implmenting military and government computer systems for classified or sensitive data. You also need the other half of the equation, the Protection Profile, what it is trying to achieve. There is a far greater focus on access control, and auditing than in your typically commercial computing setting. It is about assurance, not security.

The EAL has become a media sound bite, it is quick and easy to mention in 30 seconds, but does not tell you much on its own.

So you really need two bits of information, the Evaluation Assurance Level, 3+ in this case, which implies that they producted a lot of documentation about how SuSE Linux Enterprise Server version 8 with Service Pack 3 on IBM eServers (entire line from x86 and PowerPC series to zSeries mainframes) and in the end it meets the Controlled Access Protection Profile.

Common Criteria does not focus on failure, or how things breaks, but looks at how things are designed to operate. It does NOT look for implementation flaws in most EAL levels actually acheived.

If you do any reading on Common Criteria (CC) you will quickly realise that it has little to do with secure computing, but more with assurance that if you use a given certified system you will not be blamed for any security breaches because you choose the supposely correctly labelled systems.

If CC was more popular, maybe more software programmers would focus on good software design, because their designs have to be documented, and at high enough level, they must be independently reviewed. Good design, as well as using the available resources to eliminate classes of flaws would reduce security risks by several orders of magnitude.

...here, look at the column under "Criteria". Be careful not to slashdot it - note the .mil domain ;)

Thats a great link. All kidding aside, that is speicifically (that link) what people refer to when they discuss the standards software needs to meet to be used by the military? It was written in 1985 as well!

That's the main book of the series, the orange book, and it's usually the one people refer to when they're talking about milspec compliance in their computing systems. Remember how Microsoft claimed NT4 was C2 compliant? You can see exactly what C2 means in that book. All in all, the book still stands up well, even being almost 20 years old, because it was written to outline concepts, not specific technologies.

The higher levels of compliance require that your software actually be thoroughly examined and tested by the NCSC -- since that's really the only way to know about any covert channels that might exist. I understand that testing is extremely expensive; but I don't have any further information about it.

There are a bunch of other books in the same series, pretty much all available here. Several years back you used to be able to request a hard copy of the entire rainbow series for free from Uncle Sam, but according to this link they don't publish the hard copies anymore, just CD-ROMs, which is a pity because they were a damn good way to fill up a bookshelf with intimidating-looking manuals. :(

Thats a great link. All kidding aside, that is speicifically (that link) what people refer to when they discuss the standards software needs to meet to be used by the military? It was written in 1985 as well!

That's the main book of the series, the orange book, and it's usually the one people refer to when they're talking about milspec compliance in their computing systems. Remember how Microsoft claimed NT4 was C2 compliant? You can see exactly what C2 means in that book. All in all, the book still stands up well, even being almost 20 years old, because it was written to outline concepts, not specific technologies.

The higher levels of compliance require that your software actually be thoroughly examined and tested by the NCSC -- since that's really the only way to know about any covert channels that might exist. I understand that testing is extremely expensive; but I don't have any further information about it.

There are a bunch of other books in the same series, pretty much all available here. Several years back you used to be able to request a hard copy of the entire rainbow series for free from Uncle Sam, but according to this link they don't publish the hard copies anymore, just CD-ROMs, which is a pity because they were a damn good way to fill up a bookshelf with intimidating-looking manuals. :(

Is there any official definition of what "Military Grade" means?

Yes, the Orange Book.

You're either talking out of your arse or even worse are one of Microsofts astroturfs who have known to frequent this place.

There is no need to thank me.

This IS a great thing, it's called a trusted path. This is a security concept that's been around for a long time, but isn't widely implemented. You may be familiar with another trusted path mechanism in windows, the log in screen. It requires you to hit CTRL-ALT-DELETE to login, this is done to prevent fake login programs from fooling users.

Shouldn't they be concentrating on other things, such as actual security vulnerabilities? Seems like they're trying to say "look we're paying attention to security!" without actually doing anything that is effective...

Trusted path mechanisms are a requirement to get the NSA B2 certification for an OS (see urls below), and it most definently is an effective security measure. This may not be terribly relevant to your average user, but to someone dealing with highly confidential information on a computer it is. This feature prevents a) fake windows/programs from giving out false information under the guise of a trusted program, b) fake windows/programs from getting a user to enter sensitive data by posing as a legitimate form for sensitive data entry.

http://www.radium.ncsc.mil/tpep/epl/epl-by-class.h tml
http://www.astrolox.com/libraryc/orange.html

First, a few clarifications about the CC itself. The CC lets users pick the requirements that they want, and vendors to state the requirements they happen to meet. The CC by itself doesn't require you to have this particular requirement. Instead, what's happening is that the CC defines a standard set of security requirements, and users are supposed to then identify the requirements they believe they need (using something called a "Protection Profile" (PP)). Then vendors can show whether or not they meet them. Now, it may be true that your customers are imposing this requirement for their needs, but that's different than claiming anything general about the CC.

More specifically, I suspect you're talking about the CC requirements in FDP_RIP (Residual Information Protection). But the CC is like a Chinese Menu; whether or not users want it is determined by users, and whether or not a vendor provides it (and someone is willing to pay to evaluate the function) is another. And in the CC, even if you select FDP_RIP as a requirement, there's a choice about WHEN you erase information (it may be set by the user, or stated by the vendor).

For example, the Controlled Access Protection Profile (CAPP) corresponds more-or-less to the old "Orange Book" C2 level. There are other PPs that apply to operating systems, too. But the CAPP was used to evaluate other operating systems, so it's fair to use it as an example. The CAPP does select the CC function FDP_RIP.2, "Object Residual Information Protection" requirement, so users who are requiring CAPP will require it. But its text simply says that "The TSF shall ensure that any previous information content of a resource is made unavailable upon the allocation of the resource to all objects." There's a clarifying note in the CAPP that "Clearing the information content of resources on deallocation from objects is sufficient to satisfy this requirement, if unallocated resources will not accumulate new information until they are allocated again." It also includes a similar "Subject Residual Information Protection" requirement, stating that "The TSF shall ensure that any previous information content of a resource is made unavailable upon the allocation of the resource to all subjects." See CAPP sections 5.2.3 and 5.2.4.

(Oh, a few quick definitions first for those who don't know. Oversimplifying things, think of "subject" as Linux thread/process, and "object" as data such as filesystem objects, network packets, or memory. A "TOE" is the Target of Evaluation (think "this particular version of GNU/Linux configured a particular way"), and a "TSF" is the TOE security functions (it's the subset of the system responsible for security, including the Linux kernel, processes that run as root, and setuid root programs). Go look at the CC for more official definitions; I'm just trying to give the jist.)

In the CC, users can determine if they want to require clearing data when it's deallocated, or when it's allocated. It appears that the CAPP (and probably many other PPs) only require it by the time it's allocated (the clarifying text hopefully makes it clear that you can clear it earlier, as long as you don't seep data back into it later).

Thus, even if you mean CC requirements like FDP_RIP.2, it appears that GNU/Linux may meet it as long as the PP specifies that it's just when it's allocated - a common user choice. There's no requirement in the CAPP that the erasure happen when the object/subject is freed - merely that the erasure happen some time before it's reused.

Alan Cox's response actually sounds like evidence that GNU/Linux might meet this requirement! Pages are cleared before being handed to another process - that handles one issue. Disk blocks are retrieved as empty disk blocks. And, for crashing, there's a slower mode that would probably be required for use in a secured situation - but that's okay, you just specify that for this kind of use, you have to turn on that configuration option.

There is a known bug in older Linux kernels - many network drivers don't clear out their data, so you can get some information leakage via network packets. That's already been patched (I forget when). It's worth noting that many other operating systems over the years have had that problem too, it's a standard thing to look for in an evaluation.

Of course, intentions are great, but the real test is if it really happens. An evaluation would look over the evidence to determine if it's reasonable to believe that all residual information really is getting cleared. How much effort would be expended to do this examination depends on the EAL level.

No computer system can be considered truly secure if the basic hardware and software mechanisms that enforce the security policy are themselves subject to unauthorized modification or subversion.

Either of those actions void the basic assumptions of the CAPP (pdf) - in particular, A.NO_EVIL_ADM and A.COOP.

A.NO_EVIL_ADM is the assumption that noone is trying to break the system.

A.COOP is the assumption that everyone using the system is working in harmony to support the aims of the system.

Vendors hated NSA's old rating process. The standards were tough, NSA did the evaluations themselves, and you only got two tries to pass. After the first evaluation, NSA told you what was wrong. If you failed on the second try, that was it - you flunked. Worst case, NSA listed your product as "Class D - This class is reserved for those systems that have been evaluated but that fail to meet the requirements for a higher evaluation class."

Later, the process became much more "vendor friendly". Evaluations are performed by outside contractors, and vendors can submit their software over and over and over again until it passes. Microsoft used this process to push NT 4 through. It took years. The evaluation process is controlled by the vendor, and there are no public reports of failure.

The "common criteria" are rather weak, down near the bottom of the old NSA criteria. And the evaluation process is almost totally under vendor control, although it does have to be performed by an outside contractor acceptable to the Government.

There's better stuff out there. Currently, the most secure OS certified is the Wang XTS-300. This is certified to level B3 of the old Red Book criteria, which is about four notches above the level Windows 2000 just reached. Various FBI and DoD systems use Wang XTS-300, which is on Wang-built Pentium II and III systems. Wang is gone, but the product has been taken over by Getronics, which keeps a low profile.

Read the data sheet for the XTS-300. It's UNIX-like, but very different inside.

Coming soon, the XTS-400, which runs Linux apps.

These secure systems enforce a "mandatory security" model. Data has a security level, an integrity level, and a list of compartments to which it belongs. Movement downward in security level or upward in integrity level is prohibited, as is movement out of a security compartment or into an integrity compartment. This is very restrictive, but it's the only approach known to have any chance of really working.

Vendors hated NSA's old rating process. The standards were tough, NSA did the evaluations themselves, and you only got two tries to pass. After the first evaluation, NSA told you what was wrong. If you failed on the second try, that was it - you flunked. Worst case, NSA listed your product as "Class D - This class is reserved for those systems that have been evaluated but that fail to meet the requirements for a higher evaluation class."

Later, the process became much more "vendor friendly". Evaluations are performed by outside contractors, and vendors can submit their software over and over and over again until it passes. Microsoft used this process to push NT 4 through. It took years. The evaluation process is controlled by the vendor, and there are no public reports of failure.

The "common criteria" are rather weak, down near the bottom of the old NSA criteria. And the evaluation process is almost totally under vendor control, although it does have to be performed by an outside contractor acceptable to the Government.

There's better stuff out there. Currently, the most secure OS certified is the Wang XTS-300. This is certified to level B3 of the old Red Book criteria, which is about four notches above the level Windows 2000 just reached. Various FBI and DoD systems use Wang XTS-300, which is on Wang-built Pentium II and III systems. Wang is gone, but the product has been taken over by Getronics, which keeps a low profile.

Read the data sheet for the XTS-300. It's UNIX-like, but very different inside.

Coming soon, the XTS-400, which runs Linux apps.

These secure systems enforce a "mandatory security" model. Data has a security level, an integrity level, and a list of compartments to which it belongs. Movement downward in security level or upward in integrity level is prohibited, as is movement out of a security compartment or into an integrity compartment. This is very restrictive, but it's the only approach known to have any chance of really working.

Vendors hated NSA's old rating process. The standards were tough, NSA did the evaluations themselves, and you only got two tries to pass. After the first evaluation, NSA told you what was wrong. If you failed on the second try, that was it - you flunked. Worst case, NSA listed your product as "Class D - This class is reserved for those systems that have been evaluated but that fail to meet the requirements for a higher evaluation class."

Later, the process became much more "vendor friendly". Evaluations are performed by outside contractors, and vendors can submit their software over and over and over again until it passes. Microsoft used this process to push NT 4 through. It took years. The evaluation process is controlled by the vendor, and there are no public reports of failure.

The "common criteria" are rather weak, down near the bottom of the old NSA criteria. And the evaluation process is almost totally under vendor control, although it does have to be performed by an outside contractor acceptable to the Government.

There's better stuff out there. Currently, the most secure OS certified is the Wang XTS-300. This is certified to level B3 of the old Red Book criteria, which is about four notches above the level Windows 2000 just reached. Various FBI and DoD systems use Wang XTS-300, which is on Wang-built Pentium II and III systems. Wang is gone, but the product has been taken over by Getronics, which keeps a low profile.

Read the data sheet for the XTS-300. It's UNIX-like, but very different inside.

Coming soon, the XTS-400, which runs Linux apps.

These secure systems enforce a "mandatory security" model. Data has a security level, an integrity level, and a list of compartments to which it belongs. Movement downward in security level or upward in integrity level is prohibited, as is movement out of a security compartment or into an integrity compartment. This is very restrictive, but it's the only approach known to have any chance of really working.

Jonathan S. Shapiro, Ph.D.
Johns Hopkins University Information Security Institute

By now, you may have heard that Microsoft has received a Common Criteria certification for Windows 2000 (with service pack 3) at Evaluation Assurance Level (EAL) 4. Since a bunch of people know that I work on operating system security and on security assurance, I've received lots of notes asking "What does this mean?" On this page I will try to answer the question. For the impatient the answer is:

• Security experts have been saying for years that the the security of the Windows family of products is hopelessly inadequate. Now there is a rigorous government certification confirming this.

Since that's a pretty strong statement, bear with me while I try to explain it in plain English.

At the risk of telling you something you already know, here is how a purchaser ought to proceed when buying a security product:

1. Assess your needs. Determine what your requirements are.

2. Decide which product you are most confident will meet those needs.

3. Buy and deploy it.

Each of these is potentially an involved process, and most customers don't have the expertise to do them effectively. Even if you did, Microsoft (or any other vendor) isn't likely to let you examine their code and design documents in order to evaluate their product.

The purpose of the Common Criteria process is to develop standard packages of commonly found requirements (called Protection Profiles) and have a standard process of independent evaluation by which an expert evaluation team arrives at a level of confidence for some particular software product.

As a customer, this makes your life simpler, because you can compare your needs against existing requirements constructed by experts and then see how well the software you are buying meets those requirements. Security requirements are fairly hard to write down correctly, but if the resulting document is annotated properly they aren't all that hard to understand.

Obviously, if you don't know your needs (requirements) you don't stand much of a chance of getting them met. Likewise, if you don't know what requirements a software product was evaluated against, the evaluation result isn't terribly useful to you in practical terms.

From the customer perspective, a Common Criteria evaluation has two parts:

1. A standardized requirements specification called a Protection Profile that says what the system is supposed to do. Sometimes there will be more than one of these -- usually a general baseline protection profile and then some others describing additional, specialized requirements.

2. An evaluation rating. This is basically an investigation by well-trained experts to determine whether the system actually meets the requirements specified in the protection profile(s). The result of the evaluation is an "Evaluation Assurance Level" which can be between 1 and 7. This number expresses the degree of confidence that you can place in the system.

In order to understand the result of an evaluation, you need to know both the evaluation result, which will be a level between EAL1 and EAL7, and the protection profile (the requirements that were tested). Given two systems evaluated against the same protection profile, a higher EAL rating is a better rating provided the requirements meet your needs.

Knowing that a product has met an EAL4 evaluation -- or even an EAL7 evaluation -- tells you absolutely nothing useful. It means that you can have some amount of confidence that the product meets an unknown set of requirements. To give a contrived example, you might need a piece of software that always paints the screen black. I might build a piece of software that paints the screen red with very high reliability, and get it evaluated at EAL4. Obviously my software isn't going to solve your problem.

Microsoft sponsored an evaluation of Windows 2000 (with Service Pack 3 and one patch) against the Controlled Access Protection Profile (plus some enhancements) and obtained an EAL4 evaluation rating. This is most accurately written as "CAPP/EAL4".

The Controlled Access Protection Profile (CAPP) standard document can be found at the Common Criteria website.Here is a description of the CAPP requirements taken from the document itself (from page 9):

• The CAPP provides for a level of protection which is appropriate for an assumed non-hostile and well-managed user community requiring protection against threats of inadvertent or casual attempts to breach the system security. The profile is not intended to be applicable to circumstances in which protection is required against determined attempts by hostile and well funded attackers to breach system security. The CAPP does not fully address the threats posed by malicious system development or administrative personnel.

Translating that into colloquial English:

• Don't hook this to the internet, don't run email, don't install software unless you can 100% trust the developer, and if anybody who works for you turns out to be out to get you you are toast.

In fairness to Microsoft, CAPP is the most complete operating system protection profile that is presently standardized. This may be the best that Microsoft can do, but it is very important for you as a user to understand that These requirements are not good enough to make the system secure. It also needs to be acknowledged that commercial UNIX-based systems like Linux aren't any better (though they are more resistant to penetration).

Note that the "Don't install software" part means that you probably shouldn't install a word processor. On several occasions Microsoft has unintentionally shipped CD's with viruses on them. A CD with a virus qualified as "malicious system development."

Having described the requirements problem, I now need to describe the problem of the EAL4 evaluation assurance level that Windows 2000 received.

As I mentioned before, EAL levels run from 1 to 7. EAL1 basically means that the vendor showed up for the meeting. EAL7 means that key parts of the system have been rigorously verified in a mathematical way. EAL4 means that the design documents were reviewed using non-challenging criteria. This is sort of like having an accounting audit where the auditor checks that all of your paperwork is there and your business practice standards are appropriate, but never actually checks that any of your numbers are correct. An EAL4 evaluation is not required to examine the software at all.

An EAL4 rating means that you did a lot of paperwork related to the software process, but says absolutely nothing about the quality of the software itself. There are no quantifiable measurements made of the software, and essentially none of the code is inspected. Buying software with an EAL4 rating is kind of like buying a home without a home inspection, only more risky.

In the case of the CAPP protection profile, there actually isn't much point to doing anything better than a low-confidence evaluation, because the requirements set itself is very weak. In effect, you would be saying "My results are inadequate, but the good news is that I've done a lot of work so that I can be really sure that the results are inadequate.

In the case of CAPP, an EAL4 evaluation tells you everything you need to know. It tells you that Microsoft spent millions of dollars producing documentation that shows that Windows 2000 meets an inadequate set of requirements, and that you can have reasonably strong confidence that this is the case.

Security isn't something that a large group can do well. It is something achieved by small groups of experts. Adding more programmers and more features makes things worse rather than better. Microsoft has been adding features demanded by their customers for a very long time.

It is possible to do much better. EROS, a research operating system that we are working on here in the Systems Research Laboratory at Johns Hopkins University, should eventually achieve an EAL7 evaluation rating, and is expected to provide total defense against viruses and malicious code. It won't be compatible, because the most important security problems in Windows and UNIX are design problems rather than implementation problems. In fact, none of the viable research efforts toward secure operating systems are compatible with existing systems.

It remains to be seen whether EROS or one of the other attempts to build secure operating systems will prevail, but better solutions are coming.

Jonathan Shapiro is an Assistant Professor in the Department of Computer Science of Johns Hopkins University. He has been working on operating system security and assurance since 1991. His past research has yielded both formally verified security properties and dramatically improved performance results in secure operating systems. His current research focuses on tying these results together into a complete, usable system, and on evaluating and testing the correctness and reliability of the resulting system.

Dr. Shapiro is also member of JHUISI, the Hopkins Information Security Institute.

These are the only Orange Book A1 certified systems: Boeing MLS LAN, Gemini Trusted Network Processor, Honeywell SCOMP. A2 ratings were never formalized as far as I know and in any event no operating system has ever made a rating above A1 (heck, only three did).

These are the only Orange Book A1 certified systems: Boeing MLS LAN, Gemini Trusted Network Processor, Honeywell SCOMP. A2 ratings were never formalized as far as I know and in any event no operating system has ever made a rating above A1 (heck, only three did).

As I understand the Common Criteria specifications, EAL 4 is the highest level of security that can be achieved without becoming cost prohibitive.

This FAQ provides a good summary of the EALs, and says:

EAL4 is the highest level at which it is likely to be economically feasible to retrofit to an existing product line.

Anything higher involves stricter controls on the original development process, ie. Microsoft would have had to go back and develop from scratch under a controlled development environment.

"The CC defines the Protection Profile (PP) construct which allows prospective consumers or developers to create standardised sets of security requirements which will meet their needs."

"The Target of Evalution (TOE) is that part of the product or system which is subject to evalution. The TOE security threats, objectives, requirements and summary specification of security focuntions and assurance measyers together form the primary inputs to the Security Targets (ST), which is used by the evalutators as basis for evaluation"

"Evaluation
The principal inputs to evalutation are the Security Target, the set of evidence about the TOE and the TOE itself. The expected result of the evalution proecess is a conformation that the ST is satisfied for the TOE, with one or more reports documenting the evalution findings"

In short the Protection Profile defines the implementation independent set of security requirements and objectives. I think the PP used for Win2000 is "Controlled Access Protection Profile (Version 1.d)", downloadable here

"The TOE (Target of Evaluation) is the product under evaluation (Win2000+VPN?+?) and the ST (security target) contains the security objectives and requirments of a specific identified TOE and defines the functional and assurance measures offered by that TOE to meet stated requirements. The ST may claim conformance to one or more PPs and forms the basis for an evalution."

The assurance level (EALx) is the measure of "how much" assurance there exists that a TOE meets its security claims. EAL1 ("bad") ... EAL7 ("good"), see above reference.

So the real interesting parts are the Security Target and the Evaluation-report. (Then you know what you're talking about).

(Yes, my native tongue is not English)

• Mandatory security and access labelling of all objects, e.g. files, processes, devices etc.
• Label integrity checking (e.g. maintenance of sensitivity 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.
• Enhanced auditing.
• Enhanced protection of Operating System.
• Improved documentation.
• Example OSes are: HP-UX BLS, Cray Research Trusted Unicos 8.0, Digital SEVMS, Harris CS/SX, SGI Trusted IRIX.

• Notification of security level changes affecting interactive users.
• Hierarchical device labels.
• Mandatory access over all objects and devices.
• Trusted path communications between user and system.
• Tracking down of covert storage channels.
• Tighter system operations mode into multilevel independent units.
• Covert channel analysis.
• Improved security testing.
• Formal models of TCB.
• Version, update and patch analysis and auditing.
• Example systems are: Honeywell Multics, Cryptek VSLAN, Trusted XENIX.

• ACLs additionally based on groups and identifiers.
• Trusted path access and authentication.
• Automatic security analysis.
• TCB models more formal.
• Auditing of security auditing events.
• Trusted recovery after system down and relevant documentation.
• Zero design flaws in TCB, and minimum implementation flaws.
• The only B3-certified OS is Getronics/Wang Federal XTS-300.

• Formal methods and proof of integrity of TCB.
• These are the only A1-certified systems: Boeing MLS LAN, Gemini Trusted Network Processor, Honeywell SCOMP.

• Mandatory security and access labelling of all objects, e.g. files, processes, devices etc.
• Label integrity checking (e.g. maintenance of sensitivity 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.
• Enhanced auditing.
• Enhanced protection of Operating System.
• Improved documentation.
• Example OSes are: HP-UX BLS, Cray Research Trusted Unicos 8.0, Digital SEVMS, Harris CS/SX, SGI Trusted IRIX.

• Notification of security level changes affecting interactive users.
• Hierarchical device labels.
• Mandatory access over all objects and devices.
• Trusted path communications between user and system.
• Tracking down of covert storage channels.
• Tighter system operations mode into multilevel independent units.
• Covert channel analysis.
• Improved security testing.
• Formal models of TCB.
• Version, update and patch analysis and auditing.
• Example systems are: Honeywell Multics, Cryptek VSLAN, Trusted XENIX.

• ACLs additionally based on groups and identifiers.
• Trusted path access and authentication.
• Automatic security analysis.
• TCB models more formal.
• Auditing of security auditing events.
• Trusted recovery after system down and relevant documentation.
• Zero design flaws in TCB, and minimum implementation flaws.
• The only B3-certified OS is Getronics/Wang Federal XTS-300.

• Formal methods and proof of integrity of TCB.
• These are the only A1-certified systems: Boeing MLS LAN, Gemini Trusted Network Processor, Honeywell SCOMP.

• Mandatory security and access labelling of all objects, e.g. files, processes, devices etc.
• Label integrity checking (e.g. maintenance of sensitivity 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.
• Enhanced auditing.
• Enhanced protection of Operating System.
• Improved documentation.
• Example OSes are: HP-UX BLS, Cray Research Trusted Unicos 8.0, Digital SEVMS, Harris CS/SX, SGI Trusted IRIX.

• Notification of security level changes affecting interactive users.
• Hierarchical device labels.
• Mandatory access over all objects and devices.
• Trusted path communications between user and system.
• Tracking down of covert storage channels.
• Tighter system operations mode into multilevel independent units.
• Covert channel analysis.
• Improved security testing.
• Formal models of TCB.
• Version, update and patch analysis and auditing.
• Example systems are: Honeywell Multics, Cryptek VSLAN, Trusted XENIX.

• ACLs additionally based on groups and identifiers.
• Trusted path access and authentication.
• Automatic security analysis.
• TCB models more formal.
• Auditing of security auditing events.
• Trusted recovery after system down and relevant documentation.
• Zero design flaws in TCB, and minimum implementation flaws.
• The only B3-certified OS is Getronics/Wang Federal XTS-300.

• Formal methods and proof of integrity of TCB.
• These are the only A1-certified systems: Boeing MLS LAN, Gemini Trusted Network Processor, Honeywell SCOMP.

• Mandatory security and access labelling of all objects, e.g. files, processes, devices etc.
• Label integrity checking (e.g. maintenance of sensitivity 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.
• Enhanced auditing.
• Enhanced protection of Operating System.
• Improved documentation.
• Example OSes are: HP-UX BLS, Cray Research Trusted Unicos 8.0, Digital SEVMS, Harris CS/SX, SGI Trusted IRIX.

• Notification of security level changes affecting interactive users.
• Hierarchical device labels.
• Mandatory access over all objects and devices.
• Trusted path communications between user and system.
• Tracking down of covert storage channels.
• Tighter system operations mode into multilevel independent units.
• Covert channel analysis.
• Improved security testing.
• Formal models of TCB.
• Version, update and patch analysis and auditing.
• Example systems are: Honeywell Multics, Cryptek VSLAN, Trusted XENIX.

• ACLs additionally based on groups and identifiers.
• Trusted path access and authentication.
• Automatic security analysis.
• TCB models more formal.
• Auditing of security auditing events.
• Trusted recovery after system down and relevant documentation.
• Zero design flaws in TCB, and minimum implementation flaws.
• The only B3-certified OS is Getronics/Wang Federal XTS-300.

• Formal methods and proof of integrity of TCB.
• These are the only A1-certified systems: Boeing MLS LAN, Gemini Trusted Network Processor, Honeywell SCOMP.

• Mandatory security and access labelling of all objects, e.g. files, processes, devices etc.
• Label integrity checking (e.g. maintenance of sensitivity 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.
• Enhanced auditing.
• Enhanced protection of Operating System.
• Improved documentation.
• Example OSes are: HP-UX BLS, Cray Research Trusted Unicos 8.0, Digital SEVMS, Harris CS/SX, SGI Trusted IRIX.

• Notification of security level changes affecting interactive users.
• Hierarchical device labels.
• Mandatory access over all objects and devices.
• Trusted path communications between user and system.
• Tracking down of covert storage channels.
• Tighter system operations mode into multilevel independent units.
• Covert channel analysis.
• Improved security testing.
• Formal models of TCB.
• Version, update and patch analysis and auditing.
• Example systems are: Honeywell Multics, Cryptek VSLAN, Trusted XENIX.

• ACLs additionally based on groups and identifiers.
• Trusted path access and authentication.
• Automatic security analysis.
• TCB models more formal.
• Auditing of security auditing events.
• Trusted recovery after system down and relevant documentation.
• Zero design flaws in TCB, and minimum implementation flaws.
• The only B3-certified OS is Getronics/Wang Federal XTS-300.

• Formal methods and proof of integrity of TCB.
• These are the only A1-certified systems: Boeing MLS LAN, Gemini Trusted Network Processor, Honeywell SCOMP.

• Mandatory security and access labelling of all objects, e.g. files, processes, devices etc.
• Label integrity checking (e.g. maintenance of sensitivity 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.
• Enhanced auditing.
• Enhanced protection of Operating System.
• Improved documentation.
• Example OSes are: HP-UX BLS, Cray Research Trusted Unicos 8.0, Digital SEVMS, Harris CS/SX, SGI Trusted IRIX.

• Notification of security level changes affecting interactive users.
• Hierarchical device labels.
• Mandatory access over all objects and devices.
• Trusted path communications between user and system.
• Tracking down of covert storage channels.
• Tighter system operations mode into multilevel independent units.
• Covert channel analysis.
• Improved security testing.
• Formal models of TCB.
• Version, update and patch analysis and auditing.
• Example systems are: Honeywell Multics, Cryptek VSLAN, Trusted XENIX.

• ACLs additionally based on groups and identifiers.
• Trusted path access and authentication.
• Automatic security analysis.
• TCB models more formal.
• Auditing of security auditing events.
• Trusted recovery after system down and relevant documentation.
• Zero design flaws in TCB, and minimum implementation flaws.
• The only B3-certified OS is Getronics/Wang Federal XTS-300.

• Formal methods and proof of integrity of TCB.
• These are the only A1-certified systems: Boeing MLS LAN, Gemini Trusted Network Processor, Honeywell SCOMP.

• Mandatory security and access labelling of all objects, e.g. files, processes, devices etc.
• Label integrity checking (e.g. maintenance of sensitivity 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.
• Enhanced auditing.
• Enhanced protection of Operating System.
• Improved documentation.
• Example OSes are: HP-UX BLS, Cray Research Trusted Unicos 8.0, Digital SEVMS, Harris CS/SX, SGI Trusted IRIX.

• Notification of security level changes affecting interactive users.
• Hierarchical device labels.
• Mandatory access over all objects and devices.
• Trusted path communications between user and system.
• Tracking down of covert storage channels.
• Tighter system operations mode into multilevel independent units.
• Covert channel analysis.
• Improved security testing.
• Formal models of TCB.
• Version, update and patch analysis and auditing.
• Example systems are: Honeywell Multics, Cryptek VSLAN, Trusted XENIX.

• ACLs additionally based on groups and identifiers.
• Trusted path access and authentication.
• Automatic security analysis.
• TCB models more formal.
• Auditing of security auditing events.
• Trusted recovery after system down and relevant documentation.
• Zero design flaws in TCB, and minimum implementation flaws.
• The only B3-certified OS is Getronics/Wang Federal XTS-300.

• Formal methods and proof of integrity of TCB.
• These are the only A1-certified systems: Boeing MLS LAN, Gemini Trusted Network Processor, Honeywell SCOMP.

• Mandatory security and access labelling of all objects, e.g. files, processes, devices etc.
• Label integrity checking (e.g. maintenance of sensitivity 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.
• Enhanced auditing.
• Enhanced protection of Operating System.
• Improved documentation.
• Example OSes are: HP-UX BLS, Cray Research Trusted Unicos 8.0, Digital SEVMS, Harris CS/SX, SGI Trusted IRIX.

• Notification of security level changes affecting interactive users.
• Hierarchical device labels.
• Mandatory access over all objects and devices.
• Trusted path communications between user and system.
• Tracking down of covert storage channels.
• Tighter system operations mode into multilevel independent units.
• Covert channel analysis.
• Improved security testing.
• Formal models of TCB.
• Version, update and patch analysis and auditing.
• Example systems are: Honeywell Multics, Cryptek VSLAN, Trusted XENIX.

• ACLs additionally based on groups and identifiers.
• Trusted path access and authentication.
• Automatic security analysis.
• TCB models more formal.
• Auditing of security auditing events.
• Trusted recovery after system down and relevant documentation.
• Zero design flaws in TCB, and minimum implementation flaws.
• The only B3-certified OS is Getronics/Wang Federal XTS-300.

• Formal methods and proof of integrity of TCB.
• These are the only A1-certified systems: Boeing MLS LAN, Gemini Trusted Network Processor, Honeywell SCOMP.