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
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
