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.

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?

When in doubt, remember:

[Anonymous Coward]

"It contains all the design mistakes you can make, and manages to even make up a few of its own." - Torvalds regarding Mach/Microkernels (Though he says it's not OSX, I still think he meant it, he just didn't want bad press so he reclassified)

"For example, I used to like the _concept_ of microkernels, I just disliked every implementation I had ever seen (both Mach and Minix included, which was the basic reason for the debate/flamewar in question). These days I've pretty much come to the conclusion that the reason few people like microkernel implementations is that the whole concept is flawed -- even if it sounds good in theory." - Torvalds

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

Wrong

[Anonymous Coward]

There are many examples of Unix systems with mandatory access controls, and role based capabilities. For Linux, you have GRsecurity, [grsecurity.net] SELinux, [nsa.gov] and RSBAC. [rsbac.org]

There are others too.

Licencing.

[Anonymous Coward]

Is it me, or is there no mention of what kind of licence it will be distributed under?

I had hoped to see some mention of one of the following:

+ GNU;
+ BSD;
or MIT.

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 ;)

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.

Interesting for inspiration only

[Anonymous Coward]

We can't just scrap the existing OSs of today, even Windows. These will simply have to be hardened as best as we can. I see a new OS as useful mostly for testing ideas that can be borrowed by other mainstream OSs.

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.

Re:Need for a superuser?

[m50d]

So a determined malicious insider can do everything they can do under traditional unix, yes. But there's defense in depth here. For example, you can probably eliminate all your setuid binaries, just give them the capabilities they need. Cdrecord gets the "set own niceness very high" capability, but a cdrecord vulnerability doesn't make a local root one. Mplayer gets the "direct access to video card" capability. People who just need to be able to mount iso images don't need the root password. It's not a panacea, but it's another layer of protection.

Re:Need for a superuser?

[3TimeLoser]

It helps separate responsibility.

I'm thinking out loud here, but let's assume there is an account or role (lets call it Auditor) that is used to create admin accounts and can recover password/encryption keys. Ideally, this account would be separate from the admin accounts used to manage the system and be the only one with access to certain audit logs/resources/encryption keys.

This way, the Auditor account cannot manage the system or have root access to the file system, but it can recover encrypted data or create/delete admin accounts. On the other hand, the admin accounts cannot administer the Auditor account or delete audit logs, but can do just about anything else on the system.

Granted, there is nothing that prevents the Auditor from resetting an admin password or creating a new admin, but that can be tightly controlled and monitored by manual process. For example, the Auditor credentials are only known by the CIO and only used when needed with direct supervision. These credentials can also be sealed and locked up in case the CIO dies or something. Any other use of those credentials should immediately throw up red flags and launch black helicopters.

It would be nice if the OS enforced these roles, and I think that's what this discussion is all about.

I'll shut up now.

Re:That's not the right question

[Doctor Memory]

It would probably be simpler to encrypt person A's encryption key with trusted person B's public key and escrow it. Then, if something happens to A, B can retrieve the key from escrow and decrypt it. You could cascade this to produce a "chain-of-command"-style process, whereby the key must be sequentially decrypted by a string of people before the original is recovered.