Hi, On Fri, Mar 24, 2006 at 12:32:08PM +0000, Sam Mason wrote: > Each user would register an agent with the system that performs the > authentication checks (this could be done though the syslog idea you > came up with previously). This process would be isolated from all > but a specific set of surrogate processes that would perform more > complicated checks (interacting with kerberos servers, keeping track > of one-time-passwords). At authentication time this agent would be > given a capability to the login device (terminal/SSH byte stream) and > would be expected to interact with it and return if the authentication > was successful or not.
Yes, this is the idea of user authentication (as opposed to system authentication, where all this is done by the system). The combination of the process and the surrogate processes is the thing that you want to run in a confined environment. That combination then says "yes" or "no", and after that you are logged in (or not). It is important that no information can be passed from the confined environment to the user's session, to avoid password logging as you noted. In fact, it is probably useful to allow the user authenticator to say "don't know", meaning the default system authenticator for the (hardware) terminal that is used is called, but that's a detail. > When authentication has passed successfully, the terminal would be passed to > the user's session init code. The surrogate processes could have the option > of attaching tokens to the login device that identify their state. No. Attaching information to the login device is communication from the authenticator to the session. If that is allowed, the process is no longer confined. In some cases it may be very useful to have such communication though. As far as I can see, those cases cannot be implemented in user code. That's why the "don't know" option is useful, because system code can pass information to the session (because it is known that it doesn't use it for malicious purposes). So there's the flexibility to add your own authenticators within the limits of security, and when untrusted code cannot be used due to security limits, system code is used instead (but of course only when the system administrator installed the desired authenticator). > > 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). > > This would be specific to each login device, and could be done by the > controlling login process. In fact, the system must have a means to show the user that "the machine is under system control, and it is safe to enter passwords". The user process must be unable to fake that. So while the user may notify the user about leaving this state, the system absolutely must do this notification (which makes it useless to do it from user code as well). This can be done with some dedicated hardware (for example, the scroll lock led could be reserved for this) which cannot be controlled by the user. An other option is a system request key, which cannot be handled by user code, but will always be handled by the system (and the user knows that pressing it will always put the system in this priviledged state). If available, a separate screen (for example a 1-character line lcd screen) can be used. And of course a combination of these could be used. > > 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. > > yes, this would be nice. but can only be done in situations where no > sensitive information is stored or you know that physical access to the > machine is controlled somehow. > > I would like to have my computer at home running like this for example. > But I would also like to have data/programs on it that are only > available when more proof of identity has been given. Marcus wrote "assign the terminal to any user in the system", not "control that user's session". What it means is that anyone can go to a terminal and say "I want to know what Joe wants to tell me" and Joe's session manager will tell whatever Joe told it to tell. The person doesn't get the "user capability bundle", but Joe's session manager _does_ get the "terminal capability bundle". > > 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. > > sounds cool, but you're saying that you want to give your login agent > at least readonly access to your account? if so then what if there > are bugs in it that an attacker manages to exploit. You don't "give readonly access to a complete account" in a capability system. ;-) Marcus' idea seems to be to have sort of a user provided program which the user agrees to run for any (unauthenticated) person. Obviously that program must not contain exploitable bugs. But even if it does, it only has the capabilities that the user provided to it, which is likely to be pretty useless for a serious cracker. > keeping the login procedure constrained should give you much more confidence > in it. Very true. Of course the user can also choose not to provide this service to unauthenticated people at all, if they feel that is better. > > > 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. > > that seems obvious in retrospect! I was mainly concerned that a bug in > the SSH server wouldn't allow one user's session to observe (or worse, > interact in) another users session. But I think this sort of thing > should be easy to guarantee. The easy part is that the system doesn't have access to the encryption keys. If the ssh public key was transferred to the user via a separate channel, the system cannot snoop the connection. That's because the user code does the decryption, the system code only transports the encrypted data. 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
