EROS FAQ: Security and Reliability
This document is part of the EROS Frequently Asked Questions list. To return to the main index, click here.
How is EROS related to Linux or other UNIX systems?
Short Answer: It isn't.
EROS and UNIX-derivatives come from very different schools about how operating systems should work.
For starters, Dennis Ritchie and Ken Thomson (who built the first UNIX system) set out in the second and subsequent versions of UNIX to build an operating system that would provide compatibility across multiple platforms. With considerable success, they build a system that provides a common source-level environment across many types of machines. They accomplished this at a time when things as basic as the size of a byte were not universally agreed on.
UNIX borrowed ideas heavily from MIT's Compatible Time Sharing System (CTSS) and also from Multics. From these places came such ideas as files and directories, user identities, and binary executable files. Each of these ideas, over the years, has proven to be a source of security challenges or flaws in the system.
Where UNIX descends from CTSS and Multics, EROS descends from KeyKOS (Key Logic, Inc.), which in turn descends from Gnosis (Tymshare). Gnosis was conceived from the ground up as a secure and reliable operating system platform. Two key decisions led the Gnosis effort in very different directions than Multics: paging and persistence. Almost all of the other differences in the system derive from these two choices early in the Gnosis architecture.
When Multics was conceived, segmentation was the order of the day. Started several years later, the Gnosis framework was based on paging rather than on segment loading. The impact of this is visible at all levels of the respective designs:
Where UNIX focuses on protecting files (a derivative of segments), EROS defines protection at the granularity of pages. This finer granularity of protection can be implemented on modern hardware MMUs directly, while files require software interpretation.
Where UNIX was forced to introduce abstractions for storing these files and translating them into runnable process images (processes, file systems), EROS simply gives every page a unique identity and then introduced a different object -- the Node -- to hold capabilities to pages and nodes.
Because UNIX processes are not preserved across restarts (doing this on a segment-based design is quite hard), some other means of validating access to files was needed. This caused user identities and access control lists to be introduced.
EROS, in contrast, simply preserves the processes across restarts. This means that there is no need to revalidate authorities. There is therefore no need to introduce any idea of user identity into the EROS supervisor. Also, there is no need to have any notion of a ``file'' in the supervisor -- the connectivity established by Nodes and Pages doesn't disappear when the system crashes.
Almost the only place where the two systems are similar is in the area of networking. A network connection is not persistent, because it must be re-authenticated after a system crash. As a result, EROS has been able to borrow heavily from the UNIX networking code.
Is it possible to run binaries from Linux or other UNIX systems under EROS?
Short Answer: Not yet, but it will be.
It's possible to build a UNIX environment that runs on top of EROS, and we intend to do so. That environment will run both conventional UNIX binaries and will also be able to access EROS-based services.
In fact, it will be possible to run multiple UNIX environments at once. If desired, each user can be given a UNIX system that they fully control and adminster, without compromising the security of the other UNIX environments on the machine.
Why is EROS secure?
The answer to this is involved. Here are a few basic points:
EROS protection is fine-grained. Instead of granting programs all of the rights of some user, EROS grants programs access to specific resources. Each program therefore runs with only the authority that it needs (the ``principle of least privilege''), which makes it inherently more secure.
EROS access rights are preserved across system restarts. This makes it feasible to divide access rights across multiple processes without tearing out your hair to get the interrelationships between those processes right after every restart.
Also, there is no need for a file system, which is a major source of security leaks.
Invocations of authority are explicit. When an EROS program invokes a capability, its authority comes from the capability that it names, not from some ambient status or authority that the process holds (i.e. not from any notion of user identity). One result is that trusted programs are much harder to compromise.
Because EROS is capability based, it is possible to strictly limit the communication channels that a program has. Among other things, user A can safely run software from an untrusted user B and know that there are no overt communication leaks. This is the kind of security that Java is trying (and failing) to provide.
In the end, all of this combines to lead to a different style of building programs. EROS programs tend to be built out of small, testable components.
Why is EROS reliable?
Once again, the answer to this question is involved. A more complete answer can be found in one of the EROS white papers here.
EROS is reliable for basically the same reasons it is secure. Each EROS component can be built to do exactly what it should and no more. This makes the components testable.
At the same time, EROS components live inside a protection boundary. This means that when they do go wrong it is much harder for them to corrupt other components and much easier to determine where the error really occurred.
Copyright 1999 by Jonathan Shapiro. All rights reserved. For terms of redistribution, see the GNU General Public License