Re: User sessions, system request

[Bas Wijnen]

Hi,

On Wed, Jan 30, 2008 at 06:54:15AM +0100, address@hidden wrote:
> On Fri, Jan 18, 2008 at 05:39:12PM +0100, Bas Wijnen wrote:
> 
> > It's been a while since anything happened here.  I haven't had any
> > comments about my kernel, which I found disappointing (I talked a bit
> > about it with Marcus, so I didn't expect new comments from him, but I
> > had expected some from others like Jonathan).
> 
> I was pretty amazed by what you had done there... And I really didn't
> know what to say. Look at it in a positive light: It was so convincing
> that there was nothing left to add or to dissent from... ;-)

Thanks. :-)

On Wed, Jan 30, 2008 at 10:50:33AM -0500, Jonathan S. Shapiro wrote:
> I apologize, but (as you have probably figured out) things have been
> very hectic, and I really don't have time to look at another kernel
> right now.

No problem, thanks for answering now. :-)  As you probably know without
looking at the kernel, the main difference with Coyotos is the lack of
constructors, and of opaque memory.  So far I'm still happy without
them. :-)

> > There must be a dedicated piece of hardware to do a "system request".
...
> > pressing alt-SysRq means first pressing alt, which the program can
> > see.  In response, it can do its worst (thinking it's about to die
> > anyway).  This must be avoided.
> 
> To be honest, the bit about Alt sounds a bit too paranoid to me...

That's fine with me. :-)  IMO the break key is unusable for anything
normal anyway, because it doesn't behave as a normal key.  So it's fine
to "sacrifice" it completely.

Even if it may be too paranoid (which I don't think it is), there's no
harm in using break, once you accept that that can't be used for
anything else.

On Wed, Jan 30, 2008 at 10:46:42AM -0500, Jonathan S. Shapiro wrote:
> Given how common keyboard sniffing software is these days, it is not
> overly paranoid.
> 
> But I'm not sure that ALT is required. On most keyboards, SysRq is an
> *unshifted* key.

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.

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.

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

> This state machine confirms that each key code sequence is "well
> formed", and passes the key code sequence along (unmodified) only when
> the full sequence has been seen. If the key code sequence for SysReq
> is seen, it is hijacked.

That's what I'm currently doing, but I'm using the break key instead of
alt-printscreen, because I don't want to require pressing alt.

> 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,
but if you want to use USB keyboards as trusted device then at least
those hubs must be trusted as well.  I think it is reasonable to make
all hub drivers trusted (also because I want to support USB gpg card
readers).  The driver for any trusted keyboard (which can be used to log
in) must indeed also be trusted, however it is possible for a user to
plug in their own keyboard in a port they control, and use their own
drivers for it.  Of course those keyboards can then not be used to
summon the login screen.  They can be used to fake it, though, and this
may be a serious security risk.  If this is considered too problematic,
the USB master driver could be instructed to handle all keyboards.
However, it would still be possible to create a special device which
looks like a keyboard, but doesn't say it is one.  However, then you're
hacking on hardware, and the OS can't successfully protect from that
anyway.

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

> More broadly, the "drivers" for any secure input and output devices, and
> any channels used by those devices to communicate to the CPU, must be
> managed by 100% trusted drivers.

Yes.  On my kernal, any program which performs direct i/o must be part
of the TCB.  This statement adds a few programs to it, which is IMO
acceptable.

> A secure system cannot let those drivers be replaced and remain
> secure. This is a well-known issue. It's known as the "trusted path"
> problem.

Right.

> 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.  Since the reserved key (pause/break)
is not generating such an event (but instead a priviledged event, which
goes to the user's session on a proper system), the window manager is
not in the trusted path.

The video driver is, though, because it presents the login screen
(indirectly).  On my system, it is also in the TCB because it performs
direct i/o.  Any other part which helps presenting the login screen is
also in the TCB.  It shouldn't be too much, though.  Only the video
driver itself can be pretty large, I think, but that is going to be TCB
anyway.

> > I need to be able to make a new user account, with all or part of
> > the rights that my own user account has.
> 
> This is interesting. I already thought about some kind of nested users,
> but only as a way to overcome UNIX limitations -- allowing a user to run
> programs with subidentities with minimal authority.

On a capability-based system, you don't need a new user for that. :-)

> I never thought about the possibility of a user creating another "true"
> user account for someone else. But it sounds useful, and natural in a
> properly designed system :-)

Yes, but care should be taken when it is used: since they are my
resources, I always have the right to inspect them.  This means that my
sub-users must fully trust me for anything they do on that machine.  In
particular, my session is part of their TCB.

This is acceptable in many cases, but not for "normal" users: it
shouldn't be used as a replacement for proper system administration. :-)

> > But if any user can make new user's accounts, then the session manager
> > really becomes simply a user itself, which has done this several
> > times. It allows its users to receive the break commands, but it gets
> > the shift-break commands itself, and goes to the user selection menu
> > when it does.  In this menu are only the "top-level" users, but that's
> > fine: after selecting which user you want, that user's session
> > provides you the login screen in the way it prefers.  If that is
> > "enter your password or select which sub-user you want to log in as",
> > my friend can also log in. :-)
> 
> Another advantage of the user-provided login screen :-)
> 
> (BTW, do you remember who originally came up with this idea? I think it
> was Marcus who mentioned it in passing and immediately discarded it
> again; and you and me who dwelt on it... But I'm not sure anymore.)

I'm not sure who mentioned it first, I actually thought it was you.  But
I do remember that convincing Marcus was slightly more work than I had
expected. :-)

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

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.  If so, the powerbox can
provide a method for entering the password which guarantees the program
that it is real.

If the program is started with a "debugging" powerbox, which is
simulating the user, there is no way it can find out.  And that's a good
thing, because programs should be able to do this.  The program
providing the powerbox (the parent) is always trusted by the child.  I
know you're not happy with that idea, but it's the basis of my system,
so it is also true here. ;-)

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

Dialogs for passwords which go to a program can be provided by the
program itself, I think.  They can't be trusted anyway.  But if there is
a reason to let the session ask the password, it's possible to add a
method for that to the powerbox.

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.

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.

> Both issues are very difficult, and they both require support from both
> hardware and software

Yes.  The software support I have for it is the hijacking of a key, and
sending it to the TCB instead of the application.

> (in particular, hardware keyboard sniffers are a serious problem).

Hardware keyboard sniffers don't exist. ;-)  Even if they do, there's
nothing that can be done about them by software (they can't even be
detected), so they don't exist. :-P

I agree they are a serious problem for people who want a secure system,
but they are of no concern to OS writers.

> 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.  These
issues mean that the pause/break key is handled by the TCB, and thus the
driver for it cannot be replaced.  Also, anything which needs port I/O
cannot be replaced.  Anything else can.  But not on a system-wide basis.

Replacing means "giving a different capability to programs which ask for
the driver capability".  So it only has any effect for as far as the
replacing program is the one who is asked for the capability.  If this
is the user's session, all programs for that user will use it.  But not
those of other users.

If it is a sub-session, which can be used for debugging, then only
programs in that sub-session will be affected.

In the real world, I think the most-used cases are the session faking a
capability for every spawned program, and the session faking it for one
specific program.  But the possibilities are endless, so users may find
new ways to do cool things. :-)

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://pcbcn10.phys.rug.nl/e-mail.html

signature.asc
Description: Digital signature