Re: SSH revised

[Bas Wijnen]

On Tue, Mar 28, 2006 at 10:48:39AM +0200, Marcus Brinkmann wrote:
> > > The user would have to learn three states the terminal can be in:
> > > System-controlled, user-controlled while being confined, and
> > > user-controlled while being unconfined.  The transition between these
> > > states would have to be visible, and must not be missed (ie, if for
> > > example you currently look away from the monitor), so they would
> > > require manual confirmation.
> > 
> > Not really.  Going from user to system code must not be missed.  I think
> > there is consensus that this is done by pressing a special key-combination
> > (system request).  The other way, however, is not so sensitive.
> > Considering there is only very limited system code, the user will
> > recognise it.
> 
> Remember that this was about not accidentially entering sensitive
> information into the wrong user account after logging in.  So this is
> about recognizing user sessions, not the system code.

If you only "looked away" after entering your username, seeing your
fingerprint and entering your password, then I don't see how suddenly a
different user can be logged in.  If you had some coffee, come back and see
that the system asks for a password, then the sensible thing to do is press
system request and check who's logged in (and reset the terminal and log in
yourself if you weren't).  But I'm not answering what you meant, because you
misunderstood me.  See below.

> > For example, when you press system request and select login, the system
> > will enter the system login manager.  The login manager will either leave
> > the terminal in a locked state (which can be left by pressing system
> > request), or with a user logged in.  In both cases, the user knows when
> > the machine is in which state.  And if there is confusion, she can always
> > press system request, which will tell her in what state the system is.  In
> > particular, the system should never say "incorrect password, try again",
> > but instead "incorrect password, press system request and try again".
> 
> After you entered the password it's too late!

Not at all.  You entered the password in the window with a yellow border,
which means it was confined and it cannot communicate it to the user's
session.  I'm just thinking of a problem with the one-time-password solution
you came up with: if the confined program has some permanent storage (that is,
which remains valid between login attempts, then the program is not confined,
because it can leak the recorded passwords to any user who provides it with a
special "list me all sniffed passwords" code.  I think this means that things
like one-time passwords can only be provided by the system, the user may only
provide code, it may not need any data to be preserved.

> > A suggestion for the login interface: There is a static background, which
> > is customized per machine, to make faking the login screen a bit harder.
> > There is a (non-fullscreen) window which is controlled by the login
> > manager.  The colour of the border of this window shows how safe it is
> > (and probably with some text (not in the window) for the colourblind).
> > Red means it's unconfined user code, which should not be trusted at all.
> > Yellow means it's confined user code, which should not be trusted for what
> > it shows, but can be trusted not to disclose sensitive information.  Green
> > means it's system code, which can be fully trusted.  Whenever user code is
> > running, the name (and "fingerprint" picture, as Marcus suggested) of that
> > user are shown outside the window, so the person on the keyboard knows
> > whose code is executing (which may change the level of trust).
> 
> You know, I kinda like watching movies full screen.

Are you watching movies within the login manager?  I would really suggest to
not make that thing any more complicated than necessary, and including a movie
player seems like a significant complication. ;-)

Seriously, when a login attempt succeeds, of course the full screen is made
available to the user's session.  All this is only happening during the login,
not after it.  It does mean that you cannot provide a full-screen movie player
to anonymous users.  These kind of things may be desirable.  For that though,
I don't think it's a problem to require explicit user action (such as pressing
a "full screen" button which is located outside the window (the one with the
red border)).

> I think that the best way to handle this would be to make it difficult to
> accidentially log in under the wrong user name.  For example, the user name
> can be read from a smart card, in addition to the "fingerprint picture" and
> so on.  Then the only thing you need to learn is to press the system reset
> key before you log in, and to be careful not to confuse yourself with
> somebody else.

This is of course true in general.  But as I see it, problems only occur after
the login succeeds (at which point you're unlikely to immediately enter your
password), not during the login procedure.

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