Re: design goals vs mechanisms (was: Re: Let's do some coding :-)

[Jonathan S. Shapiro]

On Wed, 2005-10-26 at 22:16 +0200, Marcus Brinkmann wrote:
> Capabilities, are they a goal on their own?  I don't really think so.
> They don't provide any intrinsic value.  Instead, they are a mechanism
> to implement certain access policies.  These access policies have an
> impact on what security models you can implement.  So, I think
> capabilities are a mechanism, not a goal.  As far as I know, they are
> the only feasible mechanism that allow to implement the above security
> mechanisms, if the capability mechanism is carefully designed.  The
> proof for the claim that a cap system _can_ support confinement is in
> Shap's thesis.  There may be other mechanisms that support such
> security policies (Shap can surely comment), but they are probably
> obscure.

To answer the trailing question:

The search for access control mechanisms that can demonstrably enforce
security policies has been going on for a long time, with mostly
negative results. The classic outcome on this is a formal result by
Harrison, Ruzzo, and Ullman concerning the "safety property". The safety
question asks:

  For some known initial system configuration, can we determine
  whether some particular subject (==Process) S can obtain some
  particular access right 'r' on a given object 'o'.

Here is why this matters: if you cannot control the propagation of
access rights, you can't enforce *any* policy. None.

The HRU paper asks two questions:

  Under what conditions is the safety property decidable?
  For finite systems, is it possible to *prevent* a subject S
    from obtaining this access?

The results from this paper are still considered definitive 30 years
later, and they are very very bad:

  1. In general, the problem is undecidable for almost every access
     control system we know about. This is not the important part.

  2. The safety problem is *always* decidable for finite systems
     (fortunately, this includes all systems in the real world), but the
     answer for the access control mechanisms examined was "no, you
     cannot prevent access".

     The mechanisms studied in that paper include all of the
     widely used mechanisms today, including the UNIX access model and
     the ACL model.

The *only* known system that is both generally decidable and safe is the
capability model. This much was confirmed by Jones and Snyder in 1974
(the Take-Grant paper). The RBAC model is capable of enforcing certain
very specific policies, but it does not a foundation for general policy
construction. The question remained: do capabilities provide a general
enough foundation that they can provide the brick and mortar to build
higher level security policies?

In 2000, Sam Weber and I published a formal verification that protected
capability systems could enforce confinement. This was considered a
breakthrough result. The confinement property is important because it
precisely straddles the boundary between discretionary and mandatory
access controls. Basically, if you can do confinement then you have
enough bricks and mortar to enforce any policy that is enforceable in
principle. Prior to this verification, it was universally accepted that
capabilities could not do this. This acceptance was based on a widely
cited assertion by Earl Boebert that unmodified capability systems could
not enforce the *-property. Earl has since publicly retracted his
assertion, and agreed that our verification proof is correct.

In fact, one of my students did find two minor errors in the
verification proof this year, but thankfully neither changes the
outcome.

Perhaps more important: there are two working, high-performance
implementations: the EROS constructor and the KeyKOS factory.

Because of this, I personally believe that there *is* an intrinsic value
to using a capability-based mechanism. Whether this is important to the
Hurd is something that you will have to decide.


> Is persistence a goal?  This depends on what you want to do.  If you
> want to pull the plug from your computer and see the same desktop
> before the power outage afterwards, then yes, it seems to be a goal.
> However, personally, I don't really have this goal, although it is a
> nice bonus.  I described my motivation for looking at persistence in a
> different mail ("Hurdish applications for persistence").  The goal
> would be to eradicate access control lists from the system, and
> preserve the execution context ("session") of a user's processes
> across reboots.  You correctly point out that global transparent
> persistence is not the only mechanism that supports this goal, there
> are also orthogonal persistence schemes, or even some "bootstrapping
> methods" that work more like traditional Unix (ie, you recreate the
> user session from some on-disk data format).

I agree with all of this. I would add that system-wide persistence is
*by far* the most efficient mechanism known that achieves persistence,
and that it really does simplify the implementation of some otherwise
complex bits of the system.

System-wide persistence also tends to have the effect of making the
entire system naturally transactional. For example, if you need to
update both the password file and the shadow password file, and you
crash in the middle, the update will get finished correctly when you
reboot. There aren't very many places where this is important, but the
exceptions tend to be complex, critical, and security sensitive. I don't
think that this would be a compelling reason to do persistence taken
alone, but it is a very nice thing to have.

Finally, there are certain design patterns that we (the EROS/Coyotos
team) have not been able to figure out how to do *without* persistence.
Most of these center around processes that hold authorities which are
not received from their creators. There may be ways to do this kind of
thing without persistence, and we have certainly figured how to do
*some* of the patterns we think we want, but not all of them. It is not
clear how important these patterns are to the Hurd.

One example is that I don't currently know how to build trusted paths
without system-wide persistence. On the other hand, I have not put the
kind of design attention into solving this that I would have if I really
*had* to solve the problem.

> Here are some other goals you can have: Stability, robustness

Yes. This in turn leads to another design goal.

Kernel stability and robustness isn't the goal. It's a requirement, but
it is not the goal. The goal is *application* stability and robustness.
Doing this seriously requires that we be able to break up applications
into sub-components for testing and recovery, and that these
sub-components be isolated except for their intended communication
paths. Shared memory, for example, is *very* hard to use robustly.

The implied "system" requirement is that the underlying kernel and the
core utilities must facilitate this type of application decomposition.
That is, they must work favorably to provide and support effective
isolation, and at the same time they must provide a high-performance
communication substrate. The communication mechanism is relatively easy.
The isolation support requires that we choose the right protection
primitives.

Capability-based structure has worked well in this regard for EROS and
KeyKOS. There may be other mechanisms that would also work. I do not
know of any that work as well in my opinion.

> , Small
> memory footprint (for embedded applications), 

One of my business clients is currently building a "smart" **power
strip** with 16Mbytes of memory. It's an interesting product, but it
isn't *that* smart. This objective is less important than you think. We
should not be wasteful, but neither should we be obsessive.

> Support for legacy applications...

Yes, though I think there is not yet consensus about whether a 90%
solution is needed or a 100% solution is needed.


shap