Re: Alternative network stack design (was: Re: Potential use case for opaque space bank: domain factored network stack

[Jonathan S. Shapiro]

On Mon, 2007-01-08 at 05:43 +0100, Pierre THIERRY wrote:
> Scribit Marcus Brinkmann dies 08/01/2007 hora 04:58:
> > Pierre, no matter how often you ask this question, the answer will
> > always be the same: "If anything, then only the license."  I can only
> > build a system that is secure by default.  You have to break it
> > yourself.  That is true no matter what.
> 
> The problem is, I don't see where your proposal makes the system any
> more secure than with the indiscriminate use of opaque memory. Your
> proposal makes it more complex, which is known to make a system less
> secure, in the sense that the more simple it is, the more reliably we
> can implement it correctly and find it's weaknesses.

I believe that you and Marcus are seeking different objectives. You are
focusing on whether the system is secure first. I think that Marcus is
focusing on whether the system is inspectable (by the user) first.

> The mechanism of opaque memory has been used in scientific litterature
> (could someone tell if it has already been used in deployed systems?) to
> achieve POLA at a very high level, even in system components, while
> retaining very good performance, by avoiding copy accroos protection
> boundaries...

Hmm. Pardon me for interjecting, but I believe there are several things
tangled here.

First, there is an assertion that opaque memory supports POLA. This is
not obvious, and I owe Marcus a response on this point. I will deal with
this below, but it isn't really relevant to the rest of your comment.

For the rest, I *think* that you are referring to the "Reloaded"
networking design, and perhaps to the EWS window system design.

Both designs share a common pattern: there is some service that builds a
memory region using client-supplied storage. We now need to consider
opaqueness at two levels:

1. Does the *data* in these spaces need to be opaque to the clients?

   Obviously not, since in both cases the service immediately gives the
   client read access to the data.

   In many high-performance designs, the space MUST be read-only to
   the client (client can still revoke, but not write). Here is why:

     To enhance performance, the server wants to build data structures
     in this memory and refer to those structures later. For server
     safety, the server requires a guarantee that these structures
     remain well-formed, and that the integrity assumptions of the
     server regarding these structures can only be violated by
     revoking the storage.

     If the client can write the region, the server cannot rely
     on the integrity of data structures stored there. There are
     many examples where this completely defeats the resource
     accountability benefit of having the client supply the storage.

  So this satisfies Marcus's desire to inspect, but not to insert
  (e.g.) breakpoints.

2. Does the *metadata* (that is: the mapping tables) need to be opaque
to the client?

  Realistically, if the client inspects the metadata (the nodes) of
  the space, it is inspecting an internal data structure of the server,
  but this probably does not violate any security concern.

  The client MUST NOT be able to write the metadata, because doing so
  would allow it to alter the fault behavior of references to the
  region, which is something that the service is relying on. In
  particular, the client might alter the fault handler, which would
  allow the client to ensure that a server memory reference blocks
  indefinitely. This is a denial of control flow attack against the
  service.

  But here again, readability would not be a problem.

  However, it is possible to imagine other servers where the server
  would store *capabilities* into a client-supplied capability address
  space. If so, it may be that the client should not be permitted to
  fetch *those* capabilities at all, and in that case even read access
  is too much.

The problem with translucency is that it violates POLA. It allows an
arbitrary process to inspect the storage of an arbitrary child process.
This significantly expands the authority of the parent process in a way
that is not necessary for the parent process's execution. To the extent
that this is true it is a violation of POLA.

> You [Marcus] claimed that it could be used to
> implement policies you consider to be security threats. What harmful
> policies can be achieved through this mechanism that cannot easily
> without? How does your proposal protect users from these threats? 

My impression (and I am inferring here) is that the threat Marcus refers
to is the introduction of hostile code that cannot be detected. If I
cannot inspect the service I am running, I cannot tell whether the code
it is executing is legitimate.

This is a valid concern, but it seems to me that this is a weak
argument. Code penetration can be completely prevented by using any
modern programming language, and binary inspection is not a generally
effective deterrent against a "trojan horse" that is installed at
program installation time.

However, I emphasize that this is my *opinion*. I will have more to say
on this tomorrow, because there is an interaction here with TPM that is
very unfortunate.



shap
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
+1 443 927 1719 x5100