Shawn T. Rutledge
Tue, 27 Jun 2000 19:21:24 -0700
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
> > 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 firstname.lastname@example.org
(_ | |_) http://www.bigfoot.com/~ecloud email@example.com
__) | | \________________________________________________________________
Get money for spare CPU cycles at http://www.ProcessTree.com/?sponsor=5903