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.
Coyotos, A New Security-focused OS & Language
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
It looks like they’ve discovered that finding what should and should not be restarted in a persistent system is hard.
So instead they’re trying to determine what should persist in a system where otherwise you restart everything…
I think that they’re going to find that problem to be equally hard.
The other change from Eros to Coyotos — rewriting the system using a new low level language (BitC) that you can reason about — Is very interesting. It’s about time somebody came up with a new systems programming language. Best of luck, guys!
These people actually have a clue about security. I just hope this OS becomes usable some day, and not just a nice research project. Or perhaps others would learn something from this project (and from EROS). Nah, that would be asking too much…
> These people actually have a clue about security.
That is, as opposed to the people at Microsoft, Apple, Linux, various unices, and most other OSes out there. That includes most so called “security experts”, too, who continue to push moronic per-user or per-program ACL system that have been shown time and again to not work.
I agree that C is (one) moronic language, and BitC looks very nice from a first glance.
Marcus, can you give me any good examples or pointers about what you think does not work with ACL?
It does seem that the only way to get exceptional security is with capabilities. It solves the escalation of privelidges problem because all capabilities(reading, writing, executing, etc) have to be explicitly given and can be revoked.
So in a capability system gaim would have asked and been given capabilities to read and write its config file and append to logs in .gaim, and ask for caps for sockets and such. If it had a bug all it could do would be mess with the things it has capabilities for, and the giver of the capabilities can take them away as soon as necessary.
This also allows for real privacy; there is no superuser who has access to everyone’s files(at least via the running system).
The problem with these systmes seems to be that they are very hard to write. I guess I haven’t helped though, so perhaps I ought to put my $ where et cetera.
“It does seem that the only way to get exceptional security is with capabilities. It solves the escalation of privelidges problem because all capabilities(reading,
writing, executing, etc) have to be explicitly given and can be revoked.”
That makes no sense. ACL permissions also have to be explicitly granted. What is there about a capabilities system that magically removes the possibility of exploiting bugs or misfeatures to escalate capabilities?
Standard Unix systems already have implicit capabilities, they’re just coarse-grained. Explicit capabilities give you a more finely-grained security system but it is no magic bullet.
> Standard Unix systems already have implicit capabilities,
> they’re just coarse-grained.
No, they don’t. At least not on a larger scale than “cat <in >out” (which gives cat the capability to read from “in” and write to “out”). E.g. you can’t give a window opener (i.e. a capability to open a window) to a particular instance of a program. In POS systems like linux you can’t even create (and use) groups on the fly! And even if you could, they would be program-specific and/or user-specific.
> can you give me any good examples or pointers about what
> you think does not work with ACL?
Since designation is separated from authority in ACLs you have the posibility of a confused deputy (I shouldn’t really have to say more). Also, ACLs are typically bound to users and programs, not to instanses of subsystems of programs (e.g. single threads), and they tend to be very static whereas the need for access is very dynamic.
I think “Paradigm Regained” is a good introductory paper on capability-based security, since it it directly debunks some common misconceptions that most people seems to get when introduced to the topic. Google finds it in a heartbeat.
It’s nice to see something relatively sophisticated emerging on the desktop. I’ve been using miniframe OSes like VMS and mainframe OSes like OS1100/OS2200 for almost 25 years now which have similar capabilities (no pun intended <g>), and it’s about time something like this rears its head.
> At least not on a larger scale than “cat <in >out” (which
> gives cat the capability to read from “in” and write to
> “out”).
I should point out that in most unix systems each instance of cat automatically gets the capability to read your source code, post it on some discussion forum on the internet and then delete it. That and all other authority the user that runs cat has.
The EROS project had some very interesting features, and it’s good to see that development is picked up again.
I for one, would really like to see an extremely reliable, secure OS. Something totally unhackable (0 exceptions), that runs as reliable as the hardware it’s on. There are very reliable and secure OS’s around, but it’s all about degrees of 99.999%, the 100% option still isn’t there.
For hardware, 100% reliable operation isn’t possible. Even with redundancy/clustering etc., you’re just minimizing failures to extremely low levels. But for software (being based on mathematics) 100% reliability is a reachable goal, as hard as it may be.
Whether such an OS should replace the ones in common use is another matter, but it would be good to have it around as an option.
It looks like they’ve discovered that finding what should and should not be restarted in a persistent system is hard. So instead they’re trying to determine what should persist in a system where otherwise you restart everything…
Right on. Extreme reliability needs simplicity in some places, and orthogonal persistence tends to complicate things. It seems EROS has shown developers that they’re forced to make choices here, and that they have opted for reliability, moving the persistence feature into other layers. Good choice IMHO. Persistence can be a nice thing to have, but no good to use it everywhere.
“BitC was designed by careful selection and exclusion of language features in order to support proving properties (up to and including total correctness) of critical systems programs”
That is why it is important, it is a Lisp designed to be particually hard to create the types of security bugs that plague, for example, Windows. So not only are they designing the OS to be secure, but also designing the language that it is being implemented in to be secure. I liked the EROS project, especially the capability system, the idea that if a bit of code wasn’t supposed to use a resourse it could not even know of it’s existance always seemed a good way of avoiding problems like privalige escalation as you cannot try to get the priverlege of using something if you don’t even konw of it’s existance.