This is a bit off topic, but I want to address it anyway. It is partially an account for why capability systems remain important.
[Ian (I think) wrote:]
> >> > There aren't that many security oriented OSs around :(
> >> > The only ones I can think of are NT, OS/2 (Pretty bad
> >> > security actually), Unix / Linux, and BeOS.
[I replied]
> >I think that any examination of the systems Ian lists on the
> >merits will demonstrate that they are not even a reasonable
> >beginning at seriously secure systems.
[Ian responded:]
> A well set-up version of Unix is virtually untouchable. Unix is
> also very mature, and its security has been tested over a long
> time.
I think what we have here is a difference of opinion about what "security" means.
It's fairly easy to build a system that cannot be cracked from the outside. Pulling the network cable is a good start. Pulling the plug and locking the door helps too. Both solutions are universal :-)
The security architectures of UNIX/Linux, OS/2, NT, and BeOS were relatively late concerns in the architectures of the respective systems. There is 30 years of empirical experience out there that says afterthought security doesn't work.
To set the ad hominem arguments aside, though, let me try to explain:
When I say that none of the previously mentioned systems are really designed to be secure, I mean in part that their attention to security pretty much stops at the box boundary -- you are either in or out. Once in, the internal boundaries are fairly minimal.
External (i.e. black box) security, in the end, is controlled by authentication and communication protocols that are dictated by external standards. In many cases these standards are not especially secure.
ALL of the systems named are vulnerable to external denial of service attacks, and to a great many security attacks. One critical demonstrator of this is that there exists no means to argue successfully that all security holes have been closed, or even that all security exposures have been limited to any single piece of code. This is why, in spite of the long history of testing, security problems are still being found 19+ years into the life of the UNIX design.
This is an area where capability systems are strong.
EROS is primarily concerned with security *within* the box boundary. More generally, it is concerned with the propagation of information, including both data and faults. I want to know that a subcomponent of an application is not in a position to broadcast my data to the net. I also want to know that when that subcomponent takes a dive it will not take out the whole application. Finally, I want to know that all of my carefully constructed security boundaries will be recovered after a system crash.
This is something that capability systems are potentially good at, which UNIX provably cannot handle for reasons having to do with the potential flow of information in the system. If you want to take up that last gauntlet, please first read the paper that Sam Weber and I have done, where we showed how it can be formally proven:
http://www.cis.upenn.edu/~shap/EROS/popl98.300dpi.ps
[I may have got that URL wrong -- you can find it off the 'publications' link on my home page].
The short explanation is that there is no way to prevent two UNIX processes from communicating, because they share access to a mutable resource -- the file system.
shap