Coyotos, A New Security-focused OS & Language

wap writes "For those who haven't been following the EROS project, it has now migrated to the Coyotos project. EROS, the Extremely Reliable Operating System, was a project to create an operating system whose security relied on capabilities rather than the traditional Unix model of root or non-root. Capabilities allow a rigorous verification of the security of a system, something which is not possible in Unix-style and MS Windows systems. Coyotos is to be a real-world usable implementation of the ideas from EROS, complete with a Linux emulator layer. It also specifies a new language, called BitC which allows the programmer to prove that the code implements certain semantics, thus providing another layer of verifiable security. Could this be the most leet OS and language of 2005?" Another submittor asks how this stacks up against using Systems Management and "standard" OSes.

Comments

Comparison with Multics?

[CodeArt]

How Coyotos compares with Multics? Multics was most secured OS ever created with his multi-ring security architecture and security supported directly in HW.

Re:Comparison with Multics?

[Elwood P Dowd]

Dunno about this Coyotos thing, but a major point of EROS was its checkpointing system & memory architecture. In my completely uninformed understanding, the idea was that there was no filesystem, and the persistent disk was only used to provide virtual memory and checkpoint the memory state.

So if you turn off the computer, and turn it back on again, it loads the last checkpoint, and your processes are all running and in the same state. That's what they mean by "Extremely reliable". There are supposedly processes running in KeyKOS, a similar OS, that have been running since before the computer's current hardware had been built. If that makes sense.

Dunno if Multics did that.

That's not the right question

[Anonymous Coward]

Any user could encrypt data, leaving it locked forever if the key is lost. That's just the nature of electronic keys. When someone loses a physical key there is always some way to spend enough money to open the safe or whatever. That's not true in the world of encryption. The solution to that problem lies outside of the scope of the OS. Or rather, the Unix/Linux/MS Windows designers decided to put it in the scope of the OS by making certain types of protection non-existant. But that's not a solution to the problem; that's just omitting features which should be there, like giving users good encryption tools for stored files.

Capabilities

[Tet]

a project to create an operating system whose security relied on capabilities rather than the traditional Unix model of root or non-root.

This has been possible in Linux (and some proprietary Unices) for some time now. Why the need for a separate OS? But mechanism alone won't solve your problems. You need to have suitable policies that make use of those mechanisms. And as the Fedora guys have found out with their SELinux adventures, getting the policies right for any non-trivial system is a bitch.

Re:Need for a superuser?

[Coryoth]

One of the problems I see with high levels of security without a superuser-style account is the possibility of someone leaving, dying, or forgetting his password, and not being able to get to critical business data.

In SELinux, which I am more familiar with, and which also gets rid of the "superuser" account, everything is handled by context or role. That means you can isolate a process that wants "root" access to certain files by restricting its role to one that has access to only those files. Thus there is no "root" account that has access to everything. At the same time, it's possible to create a role that allows suitable access to make changes and/or recover lost data if necessary.

I presume Coyotos, with its "capabilities" will work similarly - ie. there is no "root" account that has access to everything, but instead various capabilities that bound access to various resources.

Jedidiah

Coyotos

[Deathlizard]

Hmm. does it work with Roadrunner? :)

Son of a...

[tepples]

Imagine what happens when Microsoft tries to compete by making a buggier implementation of BitC. It'll give us yet another reason to BitC# at Microsoft.

so...

[mogrify]

#include <BitC.h>

Hmmm...

[noblesse oblige]

While that was nice, my favorite feature of EROS (besides the name) was the idea that instead of a filesystem a disk was simply non-volitile memory cache. That facilitated my next favorite idea, orthogonal persistance, the somewhat like a persistant software suspend. I'd be interested in finding out (while the home page does not say) if these were the shortcomings of EROS it was alluding to.