Re: User sessions, system request

[Jonathan S. Shapiro]

On Wed, 2008-01-30 at 18:30 +0100, Bas Wijnen wrote:
> Right.  But my keyboard driver is working around all cleverness of
> keyboards anyway.  It sends exactly one event for each make or break
> that happens.  Fake shifts are removed, prefixes are interpreted (and
> merged with the actual events), key repeat is ignored.

This will break a small number of programs, but they turn out to be
depressingly important programs.

> However, by requiring users to first press Alt before they are able to
> press SysReq, the application can get some information that it shouldn't
> have.  That's why I want it to be a single key, not a combination.

Understood. Interposing a state machine in the way that I suggested
would also resolve this.

> > Even if ALT is required, there is a fairly "simple" solution: inject a
> > low-level keyboard driver that captures key code sequences from the
> > keyboard.
> 
> This won't work: I want programs to instantly see any key that is
> pressed, if they're allowed to see it.  If you want to capture it, you'd
> need to delay sending of the Alt make code until another key is pressed,
> or until it is released, or until some arbitrary time has expired(?).

This is not an issue. The state machine only runs for one full keypress.
ALT-SysReq is a single keypress. The application cannot tell if the
individual code points have been delayed.

If you are converting everything into canonical code points, you are
already running the state machine that you need.

>   I
> don't think this is acceptable.  Say I want to use Alt as one of the
> controls in a game.  This delay would make it unplayable.  Break is
> unuable for this anyway, because it doesn't generate an event when it is
> released.

Agreed. That is a good reason to use "bare" SysRq rather than ALT-SysRq
as your system attention key. The *purpose* of SysRq was to serve as the
system attention key.

> > Note that on modern machines this means that the low-level USB channel
> > driver, keyboard driver, and all USB hub drivers must be trusted.
> 
> The USB bus driver must be trusted in any case.  The hub driver doesn't...

Since a keyboard can be plugged into a hub, the driver for any hub
between the keyboard and the CPU must be trusted.

> (I currently only have a PS/2 keyboard driver, and that must be trusted
> because it uses i/o.  This is a slight limitation of my system which I
> don't consider a problem.)

Time to upgrade. :-)

> > Unfortunately, this includes the window manager, and therefore the video
> > subsystem...
> 
> No.  The window manager (on my system at least) receives key make/break
> events from the keyboard driver...

You misunderstood the issue (or rather, I was too brief). The problem is
that the user must trust the password agent, and the window manager must
implement some of that trusted path. The window manager does not need to
be trusted with respect to keyboard input. The window manager needs to
be trusted to ensure that the password entry window cannot be simulated
by a clever program.

But I see from your later comments that you already understood this.

> > Here is a pair of "litmus test" questions:
> > 
> > If I am a user typing in a password,
> > 
> >   1. How does the receiving software know that the password is
> >      coming from the user, and not from software simulating the user?
> 
> "Normal" programs don't get passwords, in the same way that they don't
> open files.  They use their powerbox for this, and in reply they get a
> message telling them if it succeeded; the actual password doesn't go to
> the program.

This is the right goal. The problem is to ensure that a "normal" program
cannot simulate a password box well enough to fool the user into
entering a password into an unauthorized program.

> Some programs may need a password, for example a pdf reader which reads
> encrypted pdf files.  But in those cases you're lost anyway, unless you
> trust the program itself with your password.

Not necessarily. If the program is willing to delegate the password
check to some password power box, it doesn't need to receive the
password.

At a minimum, confusion should be avoided by *never* calling a string
that goes to a program a password.

> If the program is started with a "debugging" powerbox, which is
> simulating the user, there is no way it can find out.

True, but a debugging powerbox should never have access to the "real"
password powerbox, and therefore should never have access to any
sensitive password.

> >   2. How does the user know that the password they type is going
> >      to software that can be trusted to protect it, rather than
> >      software that will broadcast the password to the entire world?
> 
> The user only types her password to the session manager, which is part
> of the TCB.  Note that for sub-users, this isn't a guarantee that it is
> safe.  But that's what you accept by being a sub-user.

Sub-users do not preclude a true trusted path, but confinement is
required to achieve trusted path in this case.

But the problem here is more subtle. How does the user know that they
are typing to an authentic session manager, and that this session
manager cannot leak their password.

> On Coyotos, it can happen that an untrusted program starts a trusted
> program.  In that case, I see that you have a problem.  However, on my
> system that is not possible: all parents are part of the TCB for a
> program, so if the user doesn't trust the program's parent with the
> password, she shouldn't give it to the child either.

This is a case of mis-defining a problem away rather than solving it.
The problem to consider is that the user cannot know whether they are
talking to a sub-program or not unless there is a trusted path that can
be relied on to inform them that this is happening.

> In reality, this isn't a problem, I think.  For the user, programs are
> started by herself.  When a program starts a new program, which asks for
> a password, it looks the same as if the program itself asks for the
> password directly.

That is exactly the outcome that must be avoided in a secure design.

> Hardware keyboard sniffers...
> are a serious problem for people who want a secure system,
> but they are of no concern to OS writers.

Actually, this is one of the issues where the larger-scale NGSCB design
made productive, useful, and socially acceptable progress.

> > Both issues tend to prohibit designs in which arbitrary drivers can be
> > replaced by untrusted users.
> 
> Yes.  Well, my kernel doesn't allow as much as you seem to think.

I did not assume one way or the other. I raised the issue because some
people on l4-hurd believe that users should be able to replace almost
anything at all, and you are working in the area that clearly
illustrates why this may not be such a wonderful thing.

> I encourage people to send encrypted e-mail (see http://www.gnupg.org).

Umm. Do you mean encrypted or cryptographically signed? :-)

shap