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

Need for a superuser?

[PornMaster]

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.

How is this resolved without a superuser?

Re:Need for a superuser?

[Andreas(R)]

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.

Exhaustive password search, of course.

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

Re:Need for a superuser?

[GeckoX]

And who has the rights to create that new user that has sufficient rights to get at all of that critical data that the guy who just died left behind?

I see a bit of a chicken or an egg thing here.

There will always have to be either the concept of a superuser, or there must be a way to create an account with any rights possible, otherwise it would be a very easy system to lose data to.

So, no superuser. This means there must be some way to create an account with sufficient rights to recover lost data, which kinda undermines the security in the first place.

Hope I'm missing something ;)

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.

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.

Re:Son of a...

[Kyont]

Dang, you beat me to it. I was thinking of a version with a hyperthread-supporting local application protocol (BitCH-SLAP).

so...

[mogrify]

#include <BitC.h>

forgotten lessons of Ada 83 or too young to know?

[museumpeace]

"...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...."
Developers, promoters and users of this language should consider the fate of Ada83 language before they invest a ton of effort or money. Yes, it may be strong as Fort Knox but writing software costs money and the language supports provability but does NOT eliminate the need to do up front design and heavy integration testing at the end of a project...Only the proprietors of Fort Knox would consider the cost benefit ratio of such software worthwhile. The rest of us would have to weigh it more carefully. C-derived languages got a lot of code written quickly mostly because they did not encumber the engineer with many considerations beyond the function or behavior and representation of data...the "I'm not going to give you a chance to screw up" approach to programming embodied in Ada does not map well to typical [if somewhat shoddy] coding practices and creates a much steeper learning curve for would-be programmers. I admit I have yet to RTFA but I already have this "here we go again" feeling.

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.