l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Part 2: System Structure


From: Bas Wijnen
Subject: Re: Part 2: System Structure
Date: Fri, 19 May 2006 15:46:53 +0200
User-agent: Mutt/1.5.11+cvs20060403

On Fri, May 19, 2006 at 03:29:57PM +0200, Pierre THIERRY wrote:
> > >> Currently, I am root on my computer.  There is no way you can let
> > >> me run a program on a GNU/Linux machine where I am root without
> > >> allowing me to see the binary.
> > >Would that be different when you are the owner on the
> > >constuctor-based system? I don't think so.
> > It will be much more difficult for the machine owner,
> 
> Why? It has many times been said that only TC could make it really
> impossible, and never that without it would even be hard. When you
> install the system, you do whatever you want with it, and nothing forces
> you to give up the capabilities to any part of the TCB...

System install by default doesn't give these capabilities to the machine
owner, he would need to hack the install system to do so.  It's not a simple
matter of "not dropping them", it's a matter of "taking them out of the
prepared snapshot".  Which is pretty hard compared to what root needs to do
(nothing) to be able read/write user data.

> > With the (opaque) constructor based system you can write a loader that
> > is downloaded by the user, executes in opaque storage, verifies that,
> > and downloads the actual program into its opaque storage.
> 
> I'm not sure it is possible if the user is downloading it. How does an
> external (that is, downloaded) program would know that the capability it
> is given to check opacity is not faked?

We are assuming here that we have a system which allows creating opaque
storage and a user on it who knows this.  The program can indeed not check it.
But the user can.  Well, unless the machine owner is lying to him about what
system is on the machine of course, but the assumption is that he isn't.

So to make it clear: This isn't about remote attestation.  This is about the
user against the administrator.  The user wants to keep something private from
the administrator.  He creates opaque storage, and loads the data.  The
administrator will not be able to read this storage.  The checking part is
just to make sure the storage is indeed opaque before actually loading the
sensitive data.  It is really a check by the user, not by the program.  The
user can indeed fake the program into thinking that it's safe when it's not.
But the user doesn't want to do that.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]