l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SSH revised


From: Marcus Brinkmann
Subject: Re: SSH revised
Date: Mon, 27 Mar 2006 21:41:46 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Fri, 24 Mar 2006 15:12:40 +0000,
Sam Mason <address@hidden> wrote:
> 
> > > > 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 user would have to learn three states the terminal can be in:
System-controlled, user-controlled while being confined, and
user-controlled while being unconfined.  The transition between these
states would have to be visible, and must not be missed (ie, if for
example you currently look away from the monitor), so they would
require manual confirmation.  I don't think that's practical.  It's
already too complicated that the terminal can be system-controlled and
user-controlled, but there is little we can do about that.
 
> > 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.

The authentication daemon is the user code that does the
authentication.
 
> > 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.

No, BitC is designed for exactly one goal: Formal verification of the
model of the kernel and core system.  It's not going to be the
language the software is written on you run on your actual hardware.

> > We can't hope to solve all problems in the world :)
> 
> Aww, I had greater hopes for this project

Sorry to disappoint you.

Thanks,
Marcus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]