Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!tdatirv!sarima From: sarima@tdatirv.UUCP (Stanley Friesen) Newsgroups: comp.unix.internals Subject: Re: Trojan Horses Message-ID: <28@tdatirv.UUCP> Date: 13 Oct 90 00:32:53 GMT References: <1990Oct7.155203.13283@hq.demos.su> <18578@rpp386.cactus.org> Reply-To: sarima@tdatirv.UUCP (Stanley Friesen) Organization: Teradata Corp., Irvine Lines: 29 In article <18578@rpp386.cactus.org> jfh@rpp386.cactus.org (John F. Haugh II) writes: >This is often refered to as "the secure attention key", or SAK for >short. The idea is that some special key sequence is associated with >the user wanting to validate the path to the system. ... >Killed is a tad strong. The only real requirement is that unauthorized >access to the device be revoked. You can do this ... >In practice it seems that being overly agressive with your >desires to kill processes makes users unhappy. Suitably privileged >processes would be able to re-open the device, allowing daemons such as >biff and month to avoid losing touch with reality ... A tad strong indeed. Excessively strong I would say. Under UNIX I would suggest that the SAK suspends all jobs currently attached to the terminal, and mark the file descriptor for suspension on future I/O attampts. Perhaps the suspended processes could be aged and killed if not restarted in a reasonable amount of time, but certainly not immediately. Why suspension? As protection against accidental or malicious use of the SAK in the middle of an important activity (like editing a large source file). This would allow the user to reconnect the session again later. (Of course the login process should match sessions with users, so someone else cannot attach to my session, but this too is possible). Without a restart capability the SAK feature is just too much. -- --------------- uunet!tdatirv!sarima (Stanley Friesen)