Europe has done plenty of good research. You should have mentioned Perseus or Nizza security architectures, based on L4. TU Dresden’s Nizza platform has Linux compatibility, small high quality kernel, and a viable way to build secure desktops. It’s all FOSS too. Perseus added virtualization and trusted computing to this scheme, resulting in a FOSS release and then Turaya Security kernel (commercial). And QNX has been self-healing forever. MINIX’s author even cited it as an example of good microkernel design for reliability in an argument with Torvalds.

Good call on seL4/L4Verified, but it’s debatable: their proofs haven’t been independently checked and the system is still vaporware. OKL4 3.0, from the same people, is a high quality capability based microkernel with Linux compatibility and good assurance. OKL4 4.0 Microvisor is proprietary and probably includes (or will later) the seL4 kernel technology. I know they are making it multicore and might eventually release the proofs/code. Keep eye on it.

In United States, the MILS kernels have been coming out because the NSA wants to do that. We have led the way in secure OS’s. Here’s some U.S. B3/A1-class OS’s of the past: GEMSOS (A1, still available); Army Secure OS, ASOS (A1+); XTS-400/STOPOS (B2-B3, available); MK++ (B3-equiv, maybe avail); LOCK (A1). For MILS, there are several US products: INTEGRITY-178B (EAL6+ certified); Vxworks MILS (in evaluation to EAL6+); LynxSecure (not in evaluation, but Navy will use/evaluate it maybe). Medium assurance: SourceT for DNS, Hydra’s RTOS for app-level firewall, and McAffee SecureOS for Sidewinder. Vendors also have medium assurance RTOS’s with more flexibility and high quality middleware (TCP/IP, USB, graphics, CORBA, virtualization, etc.) to support their activities. I’m glad you mentioned Ethos, though, as it eluded me somehow.

So, we’ve already built a ton of secure and useful operating systems. The best approach to securing our computers on todays hardware and legacy software is probably that of LynxSecure. They’ve basically built a virtualization kernel that leverages Intel VT to divide the system into partitions and control information flow MILS-style. The next step is to use low defect development processes to produce middleware, good VMM’s, and isolated apps. Examples include Software Inspection Process (e.g. Fagan), Praxis Correct by Construction, Galois’ Haskell stuff, or formal methods a la seL4 or CompCert. Most basic level is isolating security-critical functionality from the main OS using things like LynxSecure and INTEGRITY Padded Cell. Nizza did this for eCommerce, OKL4 did this for Citrix, and INTEGRITY Global Services has numerous applications using INTEGRITY RTOS.

So, secure OS’s and development processes already exist in the dozens all over the world, but mainly in US. There’s a few obstacles to market saturation: they take longer to build and companies want fastest time to market; the highest security can be quite expensive and restrict features/performance for complex apps; too much dependence on legacy, untrustworthy code that would invalid security guarantees of correct apps; government and universities won’t release the OS’s taxpayers funded; no real market for high assurance. The last point bugs me the most. Honeywell’s SCOMP only sold 35,000 units after NSA begged for secure OS, then bought lower assurance stuff in mass for features or convenience. It might have been different if a A1 software firm could sell to everyone, but the US government considers high assurance B3/A1/EAL6/EAL7 software as “munitions” and they are subject to export control. Who wants to spend $25 million developing a secure platform if they can’t be sure that there’s a market for it? Nobody. If the market wants secure software, they must be willing to pay for it and wait on it.

Anyone wanting to discuss this, join me on Schneier’s blog. There’s a few of us that want true security and we get into deep discussions about the details. Google “Nick P”, “Schneier” and something like “media encryptor” “MILS” “malware” to see some of the discussions.

Most operating systems can be made pretty ‘secure’ by removing the rights of users and system accounts from files, processes, etc. but the more you do that the less general usefulness you get out of that system. As a result the security of a system always depends on what you need/want to do with it. The more general/open the use of the machine, the less security you are going to get out of it.

Also, there is a trade-off involved. Depending on the purpose of the installed system, the more you ‘secure’ it, the less usability there is available. For a web facing server, there are several things that can be done to tighten security up very well, most people never do that though.

Education is the best tool we have. Educating the techs on how to fully implement security as well as teaching ethical behavior to people who produce code.

So many programming classes in schools and books available to the public abound, yet how many teach in the same class or book that hacking or spamming or producing any malware is simply not acceptable? Very very few.

It’s like offering classes on how to use a gun. They teach how to load the gun, how to clean the gun, how to fire the gun,etc… What if they never discussed the ethical issues of using a gun? The situations in which using a gun is appropriate and acceptable.

And the evidence Kevin gives is 10 programmers working worldwide on the problem half of which are actually working on making Os’s more bug resistant not security. Not that Kevin knows the difference.