Re: SSH revised

[Bas Wijnen]

On Tue, Mar 28, 2006 at 03:54:06PM +0200, Lluis wrote:
> But... a cap. to a network connection makes any non-TCB code untrusted, 

I think you mean unconfined, not untrusted.

> right?

In general, yes, but in this case, no.  The system accepts a connection from
the network.  It then starts this confined program with access to the host
keys.  It gives that program a capability to the user ssh server and to the
socket for the network connection.  Both sides of the connection need to be
trusted (and they check this using some authentication mechenism such as
public key authentication).  The "confined" program can then talk to the user
program, or the remote side, both of which are trusted.

There are other problems when the program is taken over, though.  First, the
user (and if you're unlucky, anyone) can retrieve the host keys by taking over
the program.  Second, the program can start sending plain-text stuff to the
network.  The remote side will of course reject all this, but someone sniffing
the network can still read it all.  Actually, the remote side will likely not
reject it, because it is the one who took over the program.  That is, it is a
system service, so it wasn't written to be malicious, so it can only do
malicious things if it is taken over while running.  This is because a new
connection will get a new instance of the program, so taking over one ssh
connection does not give you access to any other connection.  Is this still
understandable?

> You can't guarantee it is confined, because a network connection makes it 
> unconfined, and even if it isn't you can't know the characteristics of a 
> remote program...

You trust the (confined) system part and your own server.  They authenticate
the remote party.  If it's ok, you trust it to be controlled by the user, and
therefore it should have "good" characteristics.

As a system, you don't trust anyone.  There is a remote program, which wants a
connection.  You have a service which allows them to contact a user session
and after that they're on their own.  The only problem is that the host keys
are leaked if there is an error in the confined server program (which as far
as the system is concerned isn't confined of course: it has access to the user
program).  Perhaps this can be fixed by negotiating the session key first, and
giving that to the confined part.  Then only the session key can be leaked,
and that is completely useless (because it allows communication between the
two parties, but they are the only ones it can be sent to anyway).

> of course, if you are logging on to a remote server, you 
> already have some sort of trust on it

Not always, but if you are going to enter passwords and such, then I suppose
you trust the system, yes.

> I don't know how the confinement tests work... is there a way to ask "are 
> you confined except for this set of caps?" or something similar? I know (or 
> think to know) that EROS makes this tests with the constructor, but "this 
> set of caps" is not static, so the constructor can't tell us about it.  

Indeed, as far as I understand it this is not possible with EROS constructor
confinement checks.  I consider this a serious limitation of the idea.
Shapiro: I suppose you're reading this, can say something about this?  (Other
people's thoughts are welcome too, of course.)

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