Re: SSH revised

[Bas Wijnen]

Hi,

On Fri, Mar 24, 2006 at 12:32:08PM +0000, Sam Mason wrote:
> Each user would register an agent with the system that performs the
> authentication checks (this could be done though the syslog idea you
> came up with previously).  This process would be isolated from all
> but a specific set of surrogate processes that would perform more
> complicated checks (interacting with kerberos servers, keeping track
> of one-time-passwords).  At authentication time this agent would be
> given a capability to the login device (terminal/SSH byte stream) and
> would be expected to interact with it and return if the authentication
> was successful or not.

Yes, this is the idea of user authentication (as opposed to system
authentication, where all this is done by the system).  The combination of the
process and the surrogate processes is the thing that you want to run in a
confined environment.  That combination then says "yes" or "no", and after
that you are logged in (or not).  It is important that no information can be
passed from the confined environment to the user's session, to avoid password
logging as you noted.

In fact, it is probably useful to allow the user authenticator to say "don't
know", meaning the default system authenticator for the (hardware) terminal
that is used is called, but that's a detail.

> When authentication has passed successfully, the terminal would be passed to
> the user's session init code.  The surrogate processes could have the option
> of attaching tokens to the login device that identify their state.

No.  Attaching information to the login device is communication from the
authenticator to the session.  If that is allowed, the process is no longer
confined.  In some cases it may be very useful to have such communication
though.  As far as I can see, those cases cannot be implemented in user code.
That's why the "don't know" option is useful, because system code can pass
information to the session (because it is known that it doesn't use it for
malicious purposes).  So there's the flexibility to add your own
authenticators within the limits of security, and when untrusted code cannot
be used due to security limits, system code is used instead (but of course
only when the system administrator installed the desired authenticator).

> > However, to really make this work you would also have to
> > indicate to the user when the authentication phase is over (because
> > that is when it is no longer necessarily safe to enter a secret), and
> > you could still not be sure if you are actually logged into the right
> > session (the malicious user's auth daemon could just grant you access).
> 
> This would be specific to each login device, and could be done by the
> controlling login process.

In fact, the system must have a means to show the user that "the machine is
under system control, and it is safe to enter passwords".  The user process
must be unable to fake that.  So while the user may notify the user about
leaving this state, the system absolutely must do this notification (which
makes it useless to do it from user code as well).  This can be done with some
dedicated hardware (for example, the scroll lock led could be reserved for
this) which cannot be controlled by the user.  An other option is a system
request key, which cannot be handled by user code, but will always be handled
by the system (and the user knows that pressing it will always put the system
in this priviledged state).  If available, a separate screen (for example a
1-character line lcd screen) can be used.  And of course a combination of
these could be used.

> > I like the concept that sitting at a terminal (and entering a user
> > name) is necessary and sufficient proof for the human to be able to
> > assign the terminal to any user in the system.
> 
> yes, this would be nice.  but can only be done in situations where no
> sensitive information is stored or you know that physical access to the
> machine is controlled somehow.
> 
> I would like to have my computer at home running like this for example.
> But I would also like to have data/programs on it that are only
> available when more proof of identity has been given.

Marcus wrote "assign the terminal to any user in the system", not "control
that user's session".  What it means is that anyone can go to a terminal and
say "I want to know what Joe wants to tell me" and Joe's session manager will
tell whatever Joe told it to tell.  The person doesn't get the "user
capability bundle", but Joe's session manager _does_ get the "terminal
capability bundle".

> > Let me give you another example: I could set up, as a user, my account
> > in a way that allows anybody at "terminal 3" to see my finger
> > information, just by entering my username at the login prompt, even if
> > they don't have an account.  That's a flexibility that you can't do if
> > the system requires full authentication before assigning the terminal.
> 
> sounds cool, but you're saying that you want to give your login agent
> at least readonly access to your account?  if so then what if there
> are bugs in it that an attacker manages to exploit.

You don't "give readonly access to a complete account" in a capability system.
;-)  Marcus' idea seems to be to have sort of a user provided program which
the user agrees to run for any (unauthenticated) person.  Obviously that
program must not contain exploitable bugs.  But even if it does, it only has
the capabilities that the user provided to it, which is likely to be pretty
useless for a serious cracker.

> keeping the login procedure constrained should give you much more confidence
> in it.

Very true.  Of course the user can also choose not to provide this service to
unauthenticated people at all, if they feel that is better.

> > > That's all starting to sound a bit frightening and I guess we just want
> > > a way of passing the unencrypted packets to user space and back. . .
> > > Humm, I think the SSH server has just become fully trusted!  or can you
> > > use the containment bits of coyotos to verify that it is only going to
> > > be sending your data encrypted to the correct socket?
> > 
> > The system part of the SSH server is of course system code, just like
> > any other terminal hardware driver.
> 
> that seems obvious in retrospect!  I was mainly concerned that a bug in
> the SSH server wouldn't allow one user's session to observe (or worse,
> interact in) another users session.  But I think this sort of thing
> should be easy to guarantee.

The easy part is that the system doesn't have access to the encryption keys.
If the ssh public key was transferred to the user via a separate channel, the
system cannot snoop the connection.  That's because the user code does the
decryption, the system code only transports the encrypted data.

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