Re:

[Rick Smith <rick_smith () securecomputing com>]

At 09:28 AM 10/29/99 -0700, Russ () cooper com wrote:
> Some of you might be interested in this...
> The University of Pennsylvania is working on a new operating system that is
> supposed to be more secure than Unix or NT because it is capabilities based.

It's always risky to pass judgement based on brief sound bites, but it's a
Saturday, so here goes:

> 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.

'Least privilege' is the bedrock of any secure OS. The challenge is to find
a way to specify the privileges in a way that is concise and verifiable. It
is a real bitch to debug things in a least privilege environment. A major
upgrade to the LOCK operating system was killed in part because it was too
hard to solve the problem of confidently defining and implementing fine
grained privileges on a large scale.

> 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.

I'm not sure what this means, particularly in the context of later
statements. However, if the interrelationships change dynamically and it's
possible to establish the 'wrong' relationship somewhere, then it sounds as
if that relationship is then propagated even across system restarts.
There's the problem of "trusted recovery" in secure computing systems and
I'm not sure how this 'feature' interacts with assurance of trusted recovery.

> Also, there is no need for a file system, which is a major source of
> security leaks.

This sounds like Marcus Ranum's A1 firewall -- yeah, it's 100% secure
because you cut the wire to the ISP. It's easy to make it "secure" when you
omit the features that people need and use. The trick is to make it secure
*with* the resources you need.

> 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.

Like domains in a type enforcement mechanism. This is good.

> 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.

I wonder if they've done a covert channel analysis on the design. It's very
hard to 'strictly limit communications channels' unless you take a very
superficial view of communications within a processor. Multiprocessing
makes it even more fun (for the attacker).

> 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.

Oh, that's too bad. Apple tried to coerce apps developers into using a
'different style of building programs' (non preemptive multitasking) for
efficiency and ease of use. Look where it got them. Personally, I love non
preemptive multitasking, and I took up with the Mac when I found out it was
the Mac's internal software style. But few people teach that style of
programming, and practitioners are rare as hen's teeth.


Rick.
smith () securecomputing com
"Internet Cryptography" at http://www.visi.com/crypto/