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
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
