Re: SSH revised

[Sam Mason]

On Fri, Mar 24, 2006 at 03:22:29PM +0100, Marcus Brinkmann wrote:
> It's a good idea to always assume that the malicious party has all the
> knowledge in the world, except a well defined small number of private
> secrets.

That's generally the assumption that I would start from as well.

> So, it seems to me that what we are aiming here is to make it very
> difficult to accidentially choose the wrong session to attach to.  The
> confinement itself does not do much about that.

I was thinking that because the credential verification and session
creation where isolated from each other then the attackers session
wouldn't know if it was the attacker (Malory) logging in or the subject
of the attack (Alice).  Thinking about it now, it would be easy for the
shell to assume that it was the Alice has just logged in, and prompt for
a password change and accept some magic key combination as proof that it
was actually Malory who had logged in.

So I guess I'm back in full agreement with you.  Once you put the password
verification in control of the user the username becomes more important
and the more feedback the user recieves about this the better.

> > 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).
> 
> All these "complicated" (actually: non-confined) checks would have to
> be carefully controlled system services.

yes, that's what I was thinking.  I tend to default to understatement

> > The
> > surrogate processes could have the option of attaching tokens to the
> > login device that identify their state.
> 
> I don't understand the last sentence.  Apart from that, it comes close
> to what I was thinking.

I was thinking that something like Kerberos would want to give the
terminal the user's login token; or the one-time-password system would
need to tell the session about how many passwords it has left.  That
sort of state.

I was saying that only these system defined non-confined services
would be able to add these tokens in an attempt to reduce the chance of
secrets escaping.

> > > 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.
> 
> Would have to be done by it, actually.  Still, it sounds cumbersome.

Cumbersome in what way? this is going to have to be thought about for
each login device, so why not put the code there?

> > > The problem of leaking the password already exists in totally
> > > different scenarios as well.  For example, I sometimes happen to enter
> > > my IRC password into the wrong emacs buffer, much to the amusements of
> > > my friends.  And I always wonder if the sysadmin of a remote machine
> > > does not log my failed attempts at remembering the right password, to
> > > fish for valid passwords on different machines I have accounts on.
> > 
> > I don't think we're going to solve that one just yet though :)
> 
> Actually, by consistently using public key authentication and a
> passphrase caching agent, I think I could solve it for me.

That'll solve it for SSH logins at least.  But in general I'm not even
sure how to recognise a password request (from code) and know when to
invoke this magical container of secrets :)

> I didn't say that having access to the terminal is
> sufficient proof that the user you attach you uses the terminal in any
> way!  A good default configuration would make the user first attach an
> authentication daemon to the terminal to check who is sitting at the
> terminal.

Not quite sure what you mean by "attach an authentication daemon to the
terminal" but if by this you mean some mechanism by which we can
increase the trust in who is accessing the session then; I agree.

> a bug in the
> network stack may allow you to sniff into other TCP/IP connections,
> and a bug in the kernel may allow you to inspect other processes.

Which is what I guess BitC will help with.

> We can't hope to solve all problems in the world :)

Aww, I had greater hopes for this project


  Sam