l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SSH revised


From: Marcus Brinkmann
Subject: Re: SSH revised
Date: Tue, 28 Mar 2006 10:48:39 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Tue, 28 Mar 2006 10:23:31 +0200,
Bas Wijnen <address@hidden> wrote:
> 
> 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.

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.

> 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!

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

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.

Thanks,
Marcus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]