GUI systems

[Shawn T. Rutledge]

On Tue, Jun 27, 2000 at 09:34:00PM -0400, Jonathan S. Shapiro wrote:
> > > There is another issue, which is more "purist" in nature: the number of
> > > programs that get notified of a restart should be kept as small as
> possible.
> >
> > If I get a redraw event, I don't have any idea whether it's because
> > I've been deiconified, because Netscape has been iconified, because the
> > screen saver has just exited, because the user has invoked the "redraw
> > screen" command, or because the system has restarted.
> 
> That's because you haven't applied error correction to the signal. Think
> about it a little more from the attacker's perspective...

I don't think I understand.

Anyway if you do a client-server GUI, then if the client (display) machine
doesn't crash while EROS crashes and restarts, then nothing happens other
than a temporary freeze-up (and maybe an alert dialog to tell the user
that it froze up, and maybe a timeout period after which the terminal
forgets it had a connection); after EROS is back up the connection could 
resume without further intervention.

If the client crashes, then there needs to be a separate mechanism anyway.
I would guess that the client would hold some kind of "capability" in
non-volatile storage of some kind, which enables it to connect to the
EROS server.  Perhaps an IP address, port and public/private keys.  When
it's powered up it connects and would have to request a whole-screen
repaint (or equivalent) wouldn't it?  I'm assuming the terminals are
non-EROS systems and thus haven't gone to as great lengths to automatically
persist whatever information that they have.  Does that introduce 
security holes also?

If you use one of those crypto smart-cards for authentication, then you
could at least ensure the private key used to encrypt the channel used 
while trying to log in would be very hard to hijack.  They're usually 
designed so that only the card can ever know the private key; attempts to 
tamper with it will cause the key to be erased.  I suppose you could get 
the smart card to do all the encrypting and decrypting of all the GUI 
data going across too, but it might be too slow.  Maybe the EROS server
could make up a random, temporary key pair, use the authentication
session to forward it to the client, and then after that it uses the 
new key for that session only.

-- 
  _______                   Shawn T. Rutledge / KB7PWD  ecloud@bigfoot.com
 (_  | |_)          http://www.bigfoot.com/~ecloud  kb7pwd@kb7pwd.ampr.org
 __) | | \________________________________________________________________
Get money for spare CPU cycles at http://www.ProcessTree.com/?sponsor=5903