Re: SSH revised

[Bas Wijnen]

On Mon, Mar 27, 2006 at 09:41:46PM +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.  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".  Of course while the login manager is running, the
system menu (with options such as log in) is permanently visible in its usual
location.

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).

This assumes that unconfined user code can run from the login manager.  That
may sound strange.  I think this is useful after Marcus' comment about showing
information to someone who didn't authenticate.  Some may want to write things
which interface with the user session (in a controlled way, of course) for
this purpose.  I think this would be useful.  For this, the login manager must
support not only "login", but also "public info".  The latter option would run
an unconfined program of that user in the window (with the red border).

> I don't think that's practical.  It's already too complicated that the
> terminal can be system-controlled and user-controlled, but there is little
> we can do about that.

I agree that the need for the user to know about trust levels is not nice.
But I don't think it has to have as big an effect on the use procedures as you
suggest.

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