Re: Design principles and ethics

[Bas Wijnen]

On Wed, May 03, 2006 at 10:20:47AM -0600, Christopher Nelson wrote:
> And how to people who make things like that get paid then?

That's a good question, and it requires a good answer.  I can't give you one,
though, since I haven't thought much about it.  But it is clear to me that
once the cost of making a copy is 0, charging people per copy just doesn't
make sense.  A new way needs to be found to pay artists for their music.  I'm
sure people who care enough about it will come up with something.

> > > If I know that no one can examine AND MODIFY my data, then I can make 
> > > assumptions regarding the legitimacy of that data.
> > 
> > But you do.  We have a protected capability system.  It's 
> > your data, and you're the only one who has access to it.  
> > This data cannot have been "stolen"
> > without you (probably by accident) giving away this 
> > capability (or copying the data to where someone else can read it).
> 
> No, you DON'T.  This is my point: because your parent has all rights to
> you, you can make no guarantees about your parent, or your parent's
> parent.  Which means that you do *not* have any idea about who is in the
> communication chain.

Ah, you're confusing yourself with a process.  The user session is a direct
child of the primary space bank.  The system design guarantees that
- The primary space bank will not disclose its contents
- The session itself (which is also part of the TCB) will not give out any
  capabilities to its space bank (but only to newly created subspacebanks).
The user's shell is a direct child of the session.  No process is going to spy
on that shell.  The user interacts with the system through this shell.  There
is no danger of spying.

A shell starts processes.  It can spy on them if it likes.  But that's the
user spying on his own processes (usually this is called debugging).  Or he
can choose to not do this.  The processes cannot see the difference.  But the
user knows: If he doesn't personally debug his programs, noone does.

However, there is a "chain of processes".  What about a browser plugin?  Can
the browser spy on it?  Yes, it can.  But this is no problem for the user
(since the browser is confined, and under control of the user) and the only
reason the plugin exists in the first place is that the browser wanted to
start it.  If the plugin does encryption, that's not to protect against the
browser: it doesn't have anything to hide, there's nothing in the plugin that
the browser couldn't have without it.

So: the process indeed doesn't know if it's spied upon, but the user does.

> The man in the middle attack works just as well in an OS as it does over a
> network.

Of course.  But there is no middle man here, except the user himself.  So
there is no danger of this kind of attack.

> My point in this case, is that the child does not know who is between it and
> the user,

No, but the user does.

> cannot make any assumptions about it, and because it's parents can
> modify it's data and present it with a "false" world view, it can never
> communicate securely with any other process.

Correct.  If the user wants to modify the communication in order to see how
the client reacts, then he can.  And it's very good that the client does not
have a defense against this type of debugging, because it's very useful.

In short: the parent is trusted.  The client cannot do anything that the
parent can't.  If there's an untrusted parent in between the user and a
sensitive client, then something's very wrong in your configuration.  If you
think this can happen in normal situations (on a system which is designed to
prevent it), then please let me know how you imagine this.

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

signature.asc
Description: Digital signature