Slashdot Mirror
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.
Site says that the lisp-like syntax is to describe the language, and that a C-like syntax could be written.
EROS was distributed under GPL (eventually). One can hope that it will be the same here.
If you browse the Eros archives, you can see that Mr. Shapiro (the creator of Eros) makes frequent references to Multics as the inspiration for Eros (and therefore Coyotos). I'm not able to answer that question myself but clearly there is a close connection between Coyotos and Multics.
Go ahead and RTFA. I'm only marginally familiar with Ada83. However, I'm a fan of functional programming languages. I can't tell you how many times I've wished for type inference and pattern matching.
The problem is that, like Haskell, I will probably never work for a company who adopts BitC.
You are not a beautiful or unique snowflake -- but you could be if you got off your ass.
> There will always have to be either the concept of a superuser
No there will not. Many secure systems exist today that have no concept at all of a superuser. Some roles have extended rights in some areas, but their access to everything else is severely curtailed. The security administrator role in a MLS (multilevel security) system can tinker with the rights of any user, but can't touch files at all, such as the audit log of his own activities. The whole concept of MLS is such that the higher your clearance, the less access you actually have. So you may be able to read top secret docs, but your copy and paste keys no longer work.
Recovery of lost data is done through backups. Backup administrators can't actually read the data they're restoring, just the metadata. Only the backup facility itself accesses the data, and its interface is very well locked down so you can't do anything unauthorized with the data. Theoretically anyway. That's the whole notion of capabilities.
And this will suffer from the same problem: capabilities and ACLs are very difficult to get right, and require extremely good tools as well as informed administrators.
For quite a while (as the OP points out) the Linux kernel hasn't checked for "uid=0". Instead it checks for one of many capabilities, like CAP_SET_SYSTEM_TIME or whatever. You can give these fine-grained capabilities to other users. SELinux does something similar for applications, letting you restrict in extremely fine-grained detail what a process can do.
The key word is fine grained. It's pretty difficult to build a sand castle if you have to move individual grains. If you can manage it, it's one hell of a sand castle, but you need tools, patterns, and layers to do it.
Implementing capabilties, roles, contexts, etc. doesn't solve anything by itself, any more than a compiler solves problems by itself. It gives us the ability to solve the problem, but we're still left with the hard work.
The most interesting work going on in this area IMO is (believe it or not) Fedora. They're trying really hard to integrate SELinux into a usable operating system. It's much harder than it looks; at the moment they only have certain services running under SELinux restrictions, but eventually they'll get to a complete model where it really will be difficult to comprimise the system.
It's not hard to secure a system; just turn it off. It's very hard to secure a system so that it allows "approved" actions and disallows everything else.
Yes, you are, so relax. If you separate the roles of creating an account (and defining the priveledges that it has) and setting/resetting/enabling the password on an account, then it takes at least two people to gain access against the wishes of the owner of the system. Most large organizations have a standard that a single role cannot do this, and they usually have the roles working in different groups within the organization.
If the data is encrypted with an N-bit symmetric key, you could escrow N-56 bits of the key with your trusted party and they could brute-force the remaining 56 bits in a few days.
Alternately, you could use secret splitting to divide the escrowed data among M trusted parties such that K of them must cooperate to recover the data.
The purpose behind the EROS or Coyotos kernels is to provide a *fast* capability-based system. You can build a capability system on top of Linux using sockets and other mechanisms; it'll just be slower. It's easier to build in some ways, but the total complexity (including Linux's complexity) is higher, so you have a bit less confidence about how secure the whole thing is.
An example of this is Plash http://freshmeat.net/projects/plash/. Plash runs processes under Linux with access to nothing by default (by putting them in a chroot() jail, etc.), except that it can make requests to objects via a socket using an object-capability protocol. Plash also provides a modified GNU libc so that normal Linux executables make their filesystem requests as object invocations, basically virtualising the filesystem.
Plash shows how unmodified Unix programs would work under EROS/Coyotos: it provides a shell (similar to Bash) that lets you run Linux programs with access to a limited set of files, in a convenient way.
It appears that Persistence was removed from Coyotos. Not sure why, as it appeared to be one of the key features in EROS that differentiated it from 'conventional' OS's. Now what I'm reading is you are simply building a capability based kernel and will run Linux on top. Yeach. Marc
More info at http://erights.org.
The ACL model (based on the notion of principal) is limited because it doesn't scale (your access matrix grows fast as you need finer level access control) and still allows compromised applications to use their permissions for the wrong purpose (confused deputy problem).
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.
Somewhere on the system, individuals or people working together must somehow be able to create users with all possible privileges, that is correct. So individually or collectively they can do anything. That is not the difference.
The difference is that just because a program e.g. needs access to a raw network interface, it does not gain those complete privileges. Such a program will only get the privilege to access the raw network interface, but not to e.g. create new users or open arbitrary files.
With most UNIX'es all-or-nothing superuser (Solaris 10, among other, implement privileges instead), any program needing a raw network interface automatically gains the right to create users, shutdown the machine, alter any file, and anything else as well.
So the main difference isn't that there is no superuser, it's that there are many superusers, each of which can only perform a subset of all possible tasks requiring extra privileges. And that means that the Helpdesk staff could for example be allowed to create new accounts, without thereby automatically gaining the right to look in any file belonging to existing users. And processes can be granted any subset of what root can do without automatically gaining all the other privileges at the same time.