Re: instance and instantiator

[Jonathan S. Shapiro]

On Thu, 2005-10-13 at 23:45 +0200, Marcus Brinkmann wrote:
> I always wondered about something related to weak.  What you say
> applies, presumably, to all kernel objects, and to a certain set of
> "standard objects".
> 
> But what if I introduce a new type of objects, where even a "read
> only" capability supports "writish operations"?  Can I then break out
> of confinement with the support of the server providing that
> capability?

The weak restriction is a conservative restriction:

        weak(endpoint-cap) => void-cap

> The actual question I think I am asking is if the interpretation of
> read/write/weak only applies to the standard objects, or if it can be
> extended to new object types, and what happens if you have object
> types that don't fit this pattern at all.

It cannot be extended in this way. The problem is that the kernel has no
way to know which objects can be trusted in this fashion.

In principle, it would be possible to introduce "privileged endpoints"
s.t. there might be certain servers that the kernel might recognize as
trustworthy. There are three problems with this in practice:

1. It is very quickly abused.
2. In consequence, not even a really stupid security evaluation
   would pass with this feature present.
3. It is the kind of privileged, non-extensible policy that Alfred
   (and I) think are a really horrible idea.

In GNOSIS, KeyKOS, EROS, CapROS, and Coyotos, the historical rule was:

  The kernel shall never rely on user-mode code -- even *trusted*
  user mode code such as the space bank -- for its correctness.

In EROS and CapROS, we have relaxed this to permit user-mode drivers.
Except where we sandbox these, we consider these to be part of the
kernel where trust issues are concerned.

HOWEVER

My description of the constructor confinement test was simplified. The
one that I described is the one that is always used in practice, but
there is another one that will probably resolve your concern even though
(I predict) you will never ever use it.

The one that I described is the one that I think of as the "absolute
confinement" test.

However, the definition of confinement does not require absolute
confinement. It only requires that there be no *unauthorized* holes. In
KeyKOS, the test was:

  constructor->isConfined(capset-of-authorized-exceptions)

where capset is yet another user-mode object that is recognized by the
constructor. The KeyKOS version of the constructor (which was called the
"factory", which will answer one of Guy's offline questions) operated a
little differently than the EROS version.

  During fabrication, unconfined capabilities are added to a
  capset that is held by the constructor.

  On confinement check, the user-supplied capset and the
  constructor's capset are compared by a set difference operation.
  If the set difference:

    ConstructorCapSet - UserCapSet

  is non-empty, then the yield is unconfined.

In EROS, we did not implement this for two reasons:

  1. In practice, it had been used rarely and we had not
     yet seen *any* motivating case in EROS.

  2. U.S. Patent 4,584,639

        http://www.cis.upenn.edu/~KeyKOS/Patent/Patent.html

The problem was that we were unable to circumvent this aspect of the
patent using documentable prior art (though in hindsight, I now know
that prior art did exist). Thankfully, the patent has now expired. The
KeyKOS team threw a big party when that patent died. Today, I would not
hesitate to implement the complete check if it ever became useful.

An interesting side-light: the capability set can be placed in a mode
where it will not return capabilities, and it will only answer yes or no
to set difference operations on other capability sets. This allows an
administrator to construct a set of capabilities that are deemed safe in
the local environment by administrative decree (e.g. for locally
connected printers). The cool part is that doing this doesn't give
unauthorized users access to those devices.

A given user or client program, of course, is free not to use this
capability set, or to construct their own opaque set and perform an
opaque set union, thereby augmenting the trusted set.

Needless to say, most users probably shouldn't be encouraged to do this,
because in practice *all* of their trust judgments are going to turn out
to be dangerous to them.


shap