User sessions, system request

[Bas Wijnen]

Hi,

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).  Therefore I didn't do
much with it for some time, but I'm now picking it up and maybe even
making it usable for some limited real-life purposes.

Because of this, I have been thinking of session management.  Since this
is not at all specific to my kernel, I think it is nice to have a
discussion about it on this list.  After all, I want the best solution,
and we want that in the new Hurd as well. :-)

So, what's it all about?  I'm talking about the programs which sit
between {the kernel and the device drivers (mostly TCB stuff)} and
{applications}.  Things in between there have to do with switching
between users, starting up and closing down programs, those sort of
things.  Here are my thoughts about how some things can be handled here:

First of all, about the hardware.  There must be a dedicated piece of
hardware to do a "system request".  This should get the user to a menu
with some system options.  The program must not be able to detect that
the user does this (unless the user specifically allows it to, which may
in some cases be done for performance reasons).  This menu has options
like "kill program" and "add permission to access [resource]".  Some of
these options may also be accessible from within programs, but they must
be reliably available for the user in a way that programs cannot fake.

And in a way the program cannot detect.  For example, the alt-SysRq was
pretty much designed for this purpose.  However, it is unusable: if we
find out that a program is malicious, and we want to stop it
immediately, 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.

There is another flaw in the AT keyboard design: the pause/break key
does not send any signal to the computer when it is released.  This
means it is impossible for software to know if it is currently pressed
down or not.  (It doesn't send repeat codes either.)

The combination of these to facts, needing a dedicated key, and having a
key which is pretty much unusable for normal use, made me decide to use
this key as "system request".  Think of it as "breaking to the system".
:-)  My current userspace parts implement this already, although they
really break the program and don't allow returning to it.

While the user session needs such a dedicated piece of hardware, so does
the user switching system.  That is, to log in on the machine there must
be a way which cannot be faked by applications.  If you perform the
"normal" log-in sequence, you must be sure that you've logged in to your
own account (and not sent you password to a sniffer, for example).  For
this, using a token reader (preferrably a GPG card, but possibly a usb
stick or something) would perhaps be the best.  But people without such
hardware should also be able to use the system.  So there should be an
other option, probably with passwords.  Entering this state doesn't have
to be undetectible.  There isn't really a risk for programs, and it can
in any case be done undetectible (except to the user session, but that
is trusted to behave as far as the user's resources are concerned, and
it doesn't have access to anything else) by first pressing break, and
pressing the key combination after that.  This can be shift-break, for
example.  It should be something with break, because that way we don't
lose another key (combinations with break can't be used by programs
anyway).

On to the software.  The device drivers should be as light as possible:
they should not need to implement any complex things if those can also
be implemented elsewhere.  The reason is that new drivers are needed
with new hardware, and complex and/or duplicated code in there means the
system gets new bugs.

The drivers provide some capabilities, which should be given to the
logged in user's session (either directly, or through a proxy, such as a
file system).  Some may also be available to users which are not logged
in.  All this work should be done by the "session manager", a program
underlying the user's sessions.

First I thought about having user's sessions directly on top of this
session manager, thus creating a "flat" system, as it is on any OS I
know.  This sounds reasonable, but it means new users can only be added
by the system administrator.  And that's something I don't want: if I
work on something with a friend, and I want him to continue to work on
it even when I'm not there, then I want him to have an account.  If I
already have one, I could "fake" this by giving away my keys (password,
or whatever shape they have).  But this is highly undesirable.  So since
I obviously should have the right to allow this, the system should make
it possible for me to do it without throwing away my session's security.
In other words, I need to be able to make a new user account, with all
or part of the rights that my own user account has.

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

A user (and thus the session manager) will have access to some
capabilities (drivers and maybe some others as well).  Some of those are
coupled to the console (keyboard, pluggable devices, sound, etc).  When
it switches sub-users, it should remove the rights from one sub-user and
(optionally, depending on the settings) give them to the other.  To
minimize wrappers for performance (going through an extra process for
every call to a capability is not a good idea), the drivers will need to
have a "revoke" operation on their master capability, which should
revoke all rights, including possibly aquired rights
(membrane-property).  This must be using some standard interface,
because the session manager can't be expected to understand all devices
for which it passes capabilities.  We don't want to add support for
every new device there, after all.

I think this e-mail is long enough by now.  I look forward to any
comments anybody might have.

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