At Thu, 23 Mar 2006 23:34:10 +0000, Sam Mason <[EMAIL PROTECTED]> wrote: > > On Thu, Mar 23, 2006 at 11:39:01PM +0100, Marcus Brinkmann wrote: > > This is pretty accurate. However, we also consider a variation. In > > the variation, in step 1 _only_ the username is supplied to the > > system. The system does not do authentication. Then step 2 and 3 > > happen. Before step 4, the user code would do the authentication > > itself. > > I'd be slightly worried about this; if I misspelled my username, > wouldn't my password be sent to some random users password logger?
The malicious user catching your passphrase would immediately use it to start a man-in-the-middle attack. Note that the underlying problem is well known, and exists for example in SSH. That's why SSH has the "known hosts" file. The problem is that without knowing who you are we can't look up the right "known hosts" file for you (ie, the list of user names you think you can use safely). That's a chicken and egg problem. It needs to be bootstrapped in some way, and there are a couple of things you can do to improve the situation: First of all, it's a good policy for the sysadmin to not allow usernames which are too similar. For example, there shouldn't be a user "O13" and "013", or "Marcus" and "Mracus". This is rather simple to do, and avoids the problem of any spelling errors, also on the side of the administrator (the log-on mechanism is not the only case where there could be misspellings, it's the same with email, the admin granting a user special privileges, etc). Another thing is: don't misspell your username. Or if you do, press the Escape sequence that resets the terminal. Now, this requires that you know that you misspelled your username. One way to help with that is to display the username on a secure display device at the terminal. This could be a protected frame on the screen, or an LCD device etc. The log-on manager could help you avoid entering the wrong username in the first place by displaying a custom picture when you enter your username (again, the system should not allow users to have similar identifying pictures---in fact, it would be best to let the system assign/generate the pictures). Say, you always get a picture of a goose when you log in. Then the picture of an elephant should make you nervous. The picture serves of course as a sort of "fingerprint" identifying your account (but one that can be checked visually in a split-second). Here is something you can do to avoid leaking the passphrase even if you enter it: the system could run the user's authentication code in a confined environment. In this case, no information can be passed from the authentication code to the user's session, so giving this piece of code a sensitive password would not cause any problems. This mechanism would require a couple of additional steps, and make it more difficult (but not impossible) to support things like one time passwords. However, to really make this work you would also have to indicate to the user when the authentication phase is over (because that is when it is no longer necessarily safe to enter a secret), and you could still not be sure if you are actually logged into the right session (the malicious user's auth daemon could just grant you access). The problem of leaking the password already exists in totally different scenarios as well. For example, I sometimes happen to enter my IRC password into the wrong emacs buffer, much to the amusements of my friends. And I always wonder if the sysadmin of a remote machine does not log my failed attempts at remembering the right password, to fish for valid passwords on different machines I have accounts on. You could also customize your own user authentication agent and your session, making it difficult to imitate. For example, you can run a simple reverse challenge-response protocol with your authentication agent, where you ask the agent something private that is not known to other potentially malicious users. The malicious user would have a hard time faking such an agent. However, this solution is quite inconvenient. I think that of the above, probably the only solution that could actually work in practice is the "picture displayed before login" idea. For text-based terminals you can make it ASCII art, or a catchy quote by some famous person, or for geeks a real fingerprint of the user name :) In any case, it provides an instant visual verification that you did the right thing, and it is enforced by the system code. The arguments above have various weaknesses, that's why I am saying it's a variation that's under consideration. However, my observation is that it is very easy to harden the system by adding a mandatory user-to-system authentication step, that comes before any user-to-user authentication step. That's a straightforward local change to the code/design, so I am not overly worried. > I'm aware that it also places limits on authentication mechanisms, but > I'm having trouble reconciling these arguments. I like the concept that sitting at a terminal (and entering a user name) is necessary and sufficient proof for the human to be able to assign the terminal to any user in the system. Let me give you another example: I could set up, as a user, my account in a way that allows anybody at "terminal 3" to see my finger information, just by entering my username at the login prompt, even if they don't have an account. That's a flexibility that you can't do if the system requires full authentication before assigning the terminal. > > > this relies on each user registering some login agent with each > > > authentication process in the system (i.e. local terminal login, > > > SSH login, etc.) before logins to the user's account can happen. > > > > Not really. First, we do not need to send the capability to the user, > > the user can ask for it with a blocking fetch operation. > > OK, the mechanics don't bother me much at the moment. But some user's > process would have to contact some central process for any login to occur. Yes. It can also work the other way around, where the system invokes the user's server. But that's only possible because of some weird properties of terminal servers in particular and doesn't generalize well. The user should do the system service invocation "get next (terminal log in) event". > > > This raises > > > the question of what to do with an account that severs all ties with > > > the outside world -- which could very well be a very useful thing to do! > > > > You can't log on to that account using the terminals, then, of course. > > > > You could still communicate to that account via other capabilities, if > > they exist. > > I was more interested in determining when a process had lost all > communication with the outside world and should be killed off. I guess > this should be the admin's job though. It's difficult to decide when a process has lost all abilities to communicate, because memory may be shared, and that's an expensive semantical check. This is likely not something that will be handled at all. The operating system can garbage collect non-reachable objects from the object store, though. The storage will be given back to the space bank, but I don't think the user's reserve can be increased again, so for the user the storage is effectively leaked. The solution to this is to use nested space banks and clean up the resources of a program that you want to kill by shooting the sub space bank. We don't want to do reference counting and implicit destruction on deallocation of the last reference (except for the POSIX emulation layer). But this is really a very different topic :) > > So, in order to support other > > functions of SSH, you need to separate the protocol handling into a > > system layer and a user layer. The interface between the system and > > the user needs to reflec this. Ie, the system needs to pass off the > > SSH connection, with some of its state, to the user. It was not clear > > to me that this is possible, although Niels mail told us that it is. > > Strange, I don't think I got Niels email. The list was CC'ed, but it didn't went through (yet?). > > In particular, if we want to do the variation above, the username > > needs to be received by the system code, but the credential > > verification needs to be done by the user. So, the split may happen > > at an inconvenient place, and certainly long before the pty creation > > step. > > Baring my concerns above, I agree. > > > In other words: Terminals consist of physical or logical devices that > > the user needs to know how to use. For SSH, there will be some funny > > logical device, that is not a PTY, but represents an existing SSH > > connection, with channels and what not. > > are you suggesting that this "logical device" is only to be used in the > context of SSH connections? or would it make sense to try and generalise > this a bit? i.e. the other end of the connection wants to set up a new > PTY, a new incoming/outgoing port, wants access to your file system! I don't know how the interface of the logical device would/should look like. I suppose that the logical device would sort of represent the encrypted low level transport layer to the client side. The user would have to implement all the higher level protocol stuff of SSH themselves. Ie, PTY set up, new ports, etc. > That's all starting to sound a bit frightening and I guess we just want > a way of passing the unencrypted packets to user space and back. . . > Humm, I think the SSH server has just become fully trusted! or can you > use the containment bits of coyotos to verify that it is only going to > be sending your data encrypted to the correct socket? The system part of the SSH server is of course system code, just like any other terminal hardware driver. Thanks, Marcus _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
