Re: Restricted storage

[Jonathan S. Shapiro]

On Mon, 2006-05-29 at 13:37 +0200, Pierre THIERRY wrote:
> Scribit Bas Wijnen dies 29/05/2006 hora 11:16:
> > - There are two types of restricted storage: read-only, and no-access.
> > Both types do not provide access to the capabilities of the running
> > program.
> 
> I don't see why there should be an automatic distinction between data
> and capabilities pages. This breaks the Flexibility requirement. I'll
> suggest the following permissions, that could be applied to data or caps
> or both:
> 
> - read/write
> - read
> - none

Here is why:

Read permission on capabilities implies transitive write permission.
Therefore, if you want to be able to build programs whose write access
is restricted, you *must* be able to restrict their read accesses to
capabilities.

Specifically, consider:

   Process P holds RO cap to CapPage CP
   CapPage CP slot 5 holds RW cap to some page PG

P can write outward by

   tmp := CP[5];
   ;; map tmp into address space
   ;; store to that page

This is the entire reason for the WEAK access restriction in EROS.
Without this, you cannot do confinement cost-effectively (it can be
done, but requires deep-copy of state at constructor fabrication time).

> I wonder if a write notice flag could be interesting. If that flag was
> activated, some process would be notified when the corresponding pages
> were written. That could allow a parent to write it's child's storage,
> but still enable the integrity verification of the child by another
> process (there would be a need for an integrity protocol, though).

This notice generally comes too late to be any good -- the horse has
already left the barn. Also, it requires dynamic monitoring that is
generally agreed to be too expensive in practice. A comparable technique
has sometimes been used to handle dynamic security level tainting in MLS
systems.

> In general, some capabilities typically given by the constructor need
> only to be read-only, for example the TCB ones, like to the
> meta-constructor and the constructor.

This is incorrect. Both of these are "entry" capabilities (i.e.
capabilities to send to a process that implements some object). A "send"
capability can never be considered read-only by the kernel, because the
kernel has no way to know whether the behavior of the server is actually
read-only.

> > - When a user starts a sub-Hurd (or debugs a program in some other
> > way), it must be impossible for the program, or any of the programs it
> > spawns on its own storage, to become restricted.
> 
> Then again, this breaks Flexibility.

I have seen several references to the "Flexibility" design goal. Is this
goal described somewhere?


shap