Here are a couple projects that are worth checking out.
They have been out there for some time, and are still under construction, but they contain ideas that are pretty interesting and exciting. They are based on simple and clean principles, that aim at improving the security models while breaking down the software into numerous smaller components, for a easier development and an improved reliability.
Capabilities is a security model that mixes objects with access control.
The idea is pretty simple, but it brings lots of benefits when you look in the details: if you hold a reference/handle/capability to an object, this handle gives you some authority on that object and gives you access to some of the functions that it offers.
An analogy that is sometimes used to explain capabilities is that of a set of capabilities that you hold is like a set of keys, as it gives you access to the corresponding resources. But this analogy is somewhat limited, as this ACL vs. Capabilities article details.
This article also explains how a capability-based system have nice properties that can't be implemented via ACLs.
To summarize, capability-based systems allow a fine grain access control (that helps respecting the least privilege principle), use explicit authority (a program doesn't implicitely inherit access permissions from the user/principal who launched it and each capability explicitly binds the resource and the authority used to access it) and are elegant and uniform (no need for extra 'special' access rules to give permission to modify the access permissions themselves).
Some more information about capabilities can be found at Norman's Hardy homepage.
I first found out about capabilities on the E language homepage, when searching information about security models for mobile code in browser (ie. applets/viruses).
E is a capability-based language that can be used to implement secure distributed applications, as a chat program or a web browser, where both trust (communication/cooperation) and distrust (strong security boundaries) co-exist.
It allows virus resistant software to be written, although security needs to be analyzed during the design of an E application, to reach this goal. This means that the impact of a component being corrupted by a virus is limited, instead of compromising the whole system.
Security oriented UI:
Obviously, capabilities needs to be managed and thus made available to the user. This secure interaction design page, although more general, is definitely related to capabilities.
It lists some practical guidelines for secure interaction, with illustrated examples of the proposed do's and don'ts.
The only thing that I still find a bit mysterious about capabilities is how the permissions (expressed in the network of objects/capabilities) are set up initially, when the system starts.
EROS is a small capacity-based operating system that solves this issue by using orthogonal persistence.
This means that whenever you shutdown the system, the state is saved so that you can find all the components back in the same arrangement when you boot back up. Actually the state of the system is backed up periodically, to handle the brutal shutdown case (unplugging the computer).
Again, quite some documentation and papers are available from the EROS homepage. I think this introductory paper to EROS is a very good overview of the principles behind this OS.
EROS relies heavily on passing messages between components, and seems to have been optimized for this purpose quite a lot. Which brings me to another minimalistic message passing operating system, that I keep an eye on, as it seems promising.
The HURD is the core of the GNU operating system. Here is the HURD Homepage.
It is a microkernel based OS, that relies on a lightweight and efficient message passing interface to support many user-mode system servers. These servers implement most of the classic OS functions like filesystem, memory management, authentication, etc.
The HURD doesn't have the strong security background that EROS has with it's capability model, but instead focuses on making the OS more modularized and maintainable, although its user-mode modules design also provides some nice security improvements.
User-mode servers allow users to implement their own filesystems, for example, which traditionally was made difficult because this code belonged in the kernel (for monolithic kernels).
Also, by breaking down the system into components, simpler pieces may be designed and they may be implemented separately, which should contribute improving the quality of the software and ease the testing.
Reading all these papers about these systems really make me want to try them and I will. Probably E will come first as it seems easier to play with than EROS or HURD.
Anyway, I hope these introductions will awaken your curiosity and will lead you to learn more about those projects, which are definitely food for thought today and I hope will be great systems in practice.
I just (April 2003) found this new project, aimed at having a .NET-like platform using capability principles: Sebyla Project. I haven't had time to look at it very much yet, but it doesn't seem very advanced so far.