Capability authentication (was: cap interface for IDL4)

[Jonathan S. Shapiro]

On Fri, 2005-10-07 at 23:01 -0400, Jonathan S. Shapiro wrote:

> > > And, do we need the second one 
> > > to be provided by idl4? I say, usually the server will not trust its 
> > > client and this it's useless, as the server will not use the new handle.
> 
> You are making an incorrect assumption. In general, what you say is
> true, but if the server can authenticate the validity of a capability,
> there is no reason not to use it.

Let me start with a concrete example, and then dig in to this. What I am
about to describe is not (currently) possible in L4sec.

In EROS, we have a server that implements "space bank" objects. A space
bank is an object that allocates pages of storage and implements quotas
(EROS is persistent, so a "page" is a disk object). When a client
instantiates a new subprogram, it provides a space bank from which the
subsystem will allocate storage. This guarantees that all storage is
properly accounted for, and prevents storage denial of service attacks.

However: the subsystem may not trust the client. Imagine, for example,
that the subsystem contains some proprietary or secret data. In order
for this data to remain protected, the subsystem must know that any page
it obtains from the space bank is "exclusively held". That is: nobody
else can gain access to that same page without the consent of the
subsystem.

One of the guarantees of a space bank is that any page it allocates will
be exclusively held. The original client can destroy the entire space
bank (thereby reclaiming its storage), but the client has no way to
*examine* storage that is allocated by the subsystem.

Notice that the space bank capability is an example of a capability
provided by an untrusted (or incompletely trusted) client.

Here is the catch: the "exclusively held" guarantee cannot be relied on
unless you know that you are allocating pages from an "official" space
bank. It is not enough to be handed a capability that implements the
space bank interface. You need a way to authenticate the implementation
*behind* the interface. Otherwise, I could hand you a capability to some
process that *I* control, which lies.

EROS provides two ways to authenticate capabilities. The first is unique
to space banks. The second is generic. [The space bank is too low in the
system structure to use the generic mechanism.]

The solution for space banks is that any space bank capability can
authenticate any other space bank capability. Therefore, if we can
somehow arrange that the subsystem already holds a known-valid space
bank capability, it can check the one provided by the client. This
design pattern is so universal that there exists a widely used space
bank capability that is used solely for this purpose. It is a space bank
with a zero limit. It cannot be used to allocate storage, but it can
still be used to authenticate other banks. The general pattern is that
we arrange for all newly created processes to receive this
authenticating capability through means that are independent of their
creator.

The more general solution comes from something we call a "constructor".
A "foo constructor" is a server that knows how to create new copies of
the "foo" program. Every constructor inserts a unique, unforgeable, and
undisclosable capability into the process structure of the process that
it creates. This capability is called the "brand". Each constructor uses
a different brand from all other constructors.

In EROS, there is a kernel capability that performs (approximately) the
following operation:

        interface ProcessTool extends key {
                bool identify(entry_cap_t someProc, cap_t brand);
        }

Given an entry capability to a process and a second capability, the
kernel checks whether the second capability is equal to the existing
brand in the process. If so, it returns true, else it returns false.

By construction, only constructors hold ProcessTool capabilities.
However, if you hold a capability to a foo constructor, and you also
hold an entry capability, you can turn to the foo constructor and ask
"is this an entry capability to some process that you created?" That is:
is it an entry capability to an authentic instance of "foo"?

This authentication pattern is enormously important for many of the
security arrangements that we are able to achieve in EROS. One of my
largest concerns about L4sec is that the L4sec team does not (yet) see
that this operation is important. Without an operation like this, it is
impossible (or at least, we do not see how) to build robust third-party
trust contracts.

Some examples of things we could not achieve without this mechanism:

  Confinement
  The EROS Trusted Window System architecture
  The EROS defensible network subsystem
  The "Trusted Buffer Object"
  Trustworthy fault handlers
  Protection of proprietary or sensitive data
  Multilevel security
  Client authentication of password validation subsystems

there is more, but hopefully the point is clear: something comparable to
this mechanism is foundational in any secure object system.


shap