Re: How to add confinement to the Hurd?

[Jonathan S. Shapiro]

On Mon, 2006-05-01 at 05:30 +0200, Marcus Brinkmann wrote:
> At Mon, 1 May 2006 04:45:47 +0200,
> Pierre THIERRY <address@hidden> wrote:
> > 
> > Scribit Marcus Brinkmann dies 30/04/2006 hora 22:29:
> > > I can even tell you why there is an ethical issue.  The reason is that
> > > non-trivial confinement separates ownership of digital content into a
> > > party that has access and modification right and a party which has the
> > > right to decide durability.
> > 
> > I return to the use case of the program that is executable without
> > disclosing itself.
> > 
> > Let's state the problem clearly to avoid misunderstanding:
> > 
> > Alice writes the Processor program, whose algorithm she cannot disclose,
> > and Bob has to execute Processor on the file SensitiveData, which he
> > must keep secret. The system has to make Bob able to execute Processor
> > with the guarantee that it won't leak anything without knowing how
> > Processor work.
> > 
> > Where is access and modification separated from durability?
> 
> So, let's discuss this based on EROS.
> 
> Because of the confinement property, the program can not exclusively
> run on the resources of Alice, because then Alice could observe what
> the program does (unless the program is trivial and does not require
> any writable storage).
> 
> This means that the program must run on Bobs resources.  However, the
> way the space bank works in EROS, Bob will not be able to inspect the
> memory allocated by the program.  Bob can only shoot the space bank
> and thus revoke the resources.
> 
> So, Alice gets, indirectly, to flip the bits while Bob gets to destroy
> them.

Hmm. Now I am *completely* confused.

  Bob does not get to destroy *any* of Alice's bits, since Alice's bits
  are not at any point stored in any storage supplied by Bob.

  True, Bob cannot inspect the memory image of the program that uses
  Bob's storage, but I fail to see any intrinsic problem in this. I
  think that this must be the heart of the issue.

  As I explained in a separate note (which you probably have not had
  time to see yet) it is very simple to modify the constructor to make
  a private copy of Alice's bits into storage supplied by Bob (but not
  disclosed to him). The constructor does not do so for reasons of
  storage efficiency (mainly the ability to share code). However,
  if this copy is desired by Bob it is trivially easy to do. Given
  this I will claim (with only a little handwaving) that Alice cannot
  twiddle Bob's bits (however much Bob might enjoy that :-).

>  
> > > > 1) Do anyone knows, even remotely, what would be needed to implement
> > > > this confinement in the Hurd? Particularily, what would be needed
> > > > for the implementer to do, and what could prevent him to do it in
> > > > the Hurd design?
> > > The underlying mechanism is, at the hardware level, a "trusted
> > > computer" chip, which is a chip that contains a cryptographic key
> > > which _nobody_ can read out and which is certified by the manufacturer
> > > of the hardware.
> > 
> > I do not see how the cryptographic chip helps achieving confinement... I
> > thought it only enables certification of the system 'identity'.
> 
> Well, without a TC chip in the system the system-implemented
> confinement check relies on the good will of the machine owner.  Do
> you know how "secure booting" works?

Whether the computation is vulnerable to the physical machine owner is
an orthogonal issue to whether the confinement mechanism "works" from a
software perspective.

I agree that in the absence of TC the confinement can be violated by the
machine owner. However, under many circumstances it is reasonable to
declare either that:

  1) The machine owner is trusted, or
  2) The annoyance factor of forensics is high enough to constitute
     a tolerable risk.

I have certainly HAVE NOT and DO NOT propose that TC should be turned on
in general. That is a decision (in my opinion) that individual users
should make for themselves.


shap