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