Re: confinement with endogenous verification ??

[Jonathan S. Shapiro]

On Thu, 2005-10-27 at 12:35 +0100, Brian Brunswick wrote:
> Ah yes... I meant relative to this definition of "read-only"
> capabilities. Does the system somehow enforce that the implementation
> of a read-only capability can't save any data, or isn't that
> immediately a big channel where data can leak.

All of the capabilities that are considered transitively read only name
object types that are implemented by the kernel, so yes, the system
enforces this constraint. As I said earlier, endpoint capabilities do
not satisfy this test.

> > Yes, capabilities can be transmitted via IPC. However, an endpoint
> > capability is NOT considered to be transitively read only [exception: a
> 
> Ah, thats another question I was going to ask. Can you clarify the
> meaning of "endpoint capability" please?

An endpoint capability is the one you need to send a message (i.e.
perform an IPC) to a process.

> > Can you explain where you think the escalation is happening? The
> > constructor does not have special privilege because of any escalation.
> > All of its privilege derives directly from the capabilities that it
> > holds. The constructor does not have any special privilege beyond what
> > it's capabilities permit.
> 
> But its constructing something that has those special capabilities, on
> the demand of a client that doens't. So the client is getting some
> sort of service done for it with escalated priviledge... Exactly what
> setuid does. (only more secure we hope)

These capabilities are *not* special. They are simply not in the
possession of the client. There is no authority escalation, but I think
we need to get more specific about the distinction between authority and
permission to deal with this question:

  Permissions: the authority that you can *directly* manipulate yourself
  Authority: the set of actions that you can *transitively* cause to
    happen.

Authority is determined by a combination of two things:

  1. Reachability: things you cannot reach are things you cannot use
     to act.
  2. Code: if I put a guardian in front of something and require you
     to operate through the guardian, then the guardian can limit your
     actions.

Setuid-root is completely missing the second constraint, and also has no
effective limitation on reachability. setuid-other has only very weak
restrictions on reachability.

Unfortunately, if you think about this definition for a moment, you will
conclude that no setuid program can ever escalate its authority, because
it already *has* that authority to begin with. The real problem with
setuid is therefore NOT escalation of authority, but total abandonment
of least privilege.

setuid has another problem as well: it is an ambient authority model.
Authority is not combined with designation, and this makes "confused
deputy" scenarios the norm rather than the exception.

> >  1. The sources of covert channels can be reduced without altering
> >     the program.
> 
> How are "read-only" capability restrictions enforced for this?

I do not understand the question. The sources of covert channels have to
do with the internal multiplexing decisions of the operating system.
Read-only restrictions on capabilities are concerned only with *overt*
actions.

> >  3. Covert channels do not allow theft of information. They only allow
> >     *disclosure* of information. English: we don't need to solve the
> >     covert channel problem in order to solve the virus and hostile
> >     plugin problem.
> 
> Hmm.... not sure this is a useful distinction in the presence of
> buffer overflows and other similar bugs. Disclosure may be prompted
> too easily....

I agree with your concern, and now we are back to a discussion of "fail
open" or "fail closed" and the value of IDL in making these overruns
much harder to achieve.

> > Because of covert channels, confinement of *data* is not absolutely
> > possible. Confinement of authority (capabilities) *is* possible. This is
> > why I feel that the primary advantage of confinement as the standard
> > tool for process instantiation is its effect on system structure and
> > developer habits.
> 
> Ah ok. So confinement is confinement of capabilites. Which in a
> persistent system is really, really important. (And not much less in a
> non-p system)

Not quite. Confinement is confinement of *overt* communication (either
data or capabilities). The reason that capabilities can be covertly
confined is that the program attempting to transmit never holds the
capability in the first place, and there is no operation by which a
receiver can fabricate a capability out of thin air.

Note that cryptographic capability systems (and all other unprotected
capability systems) *are* vulnerable to capability leakage, because
capabilities are just data in such systems. This is why I said that
capability confinement could only be achieved in protected capability
systems.

shap