home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: alt.comp.acad-freedom.talk
- Path: sparky!uunet!elroy.jpl.nasa.gov!sdd.hp.com!ux1.cso.uiuc.edu!m.cs.uiuc.edu!herodotus.cs.uiuc.edu!kadie
- From: kadie@herodotus.cs.uiuc.edu (Carl M. Kadie)
- Subject: [comp.security.misc] Re: Locking terminals (was Re: New Princeton Policy)
- Message-ID: <1992Sep15.174004.29042@m.cs.uiuc.edu>
- Followup-To: alt.comp.acad-freedom.talk,comp.security.misc
- Sender: news@m.cs.uiuc.edu (News Database (admin-Mike Schwager))
- Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
- Date: Tue, 15 Sep 1992 17:40:04 GMT
- Lines: 25
-
- [A repost - Carl]
-
- From: tmal@cl.cam.ac.uk (Mark Lomas)
- Newsgroups: comp.security.misc
- Subject: Re: Locking terminals (was Re: New Princeton Policy)
- Message-ID: <1992Sep15.145424.28448@cl.cam.ac.uk>
- Date: 15 Sep 92 14:54:24 GMT
-
- The technique that I favour, and which has been adopted by at least two
- workstation vendors, is to provide a key sequence that restarts the server
- that is driving the console. The code to recognise this key sequence should
- be embedded in the device driver in such a position that it cannot be
- switched off under any circumstances.
-
- First, if the server hangs you can restart it without something as drastic
- as a reboot. Second, if somebody writes their own version of the lock
- utility then you can defeat it without the attendant risk that you gain
- access to their account. Third, you can ensure that nobody is running a
- program that masquerades as the login utility.
-
- Thus this solution has the side-effect of improving system security.
-
- Mark Lomas (tmal@cl.cam.ac.uk)
- --
- Carl Kadie -- kadie@cs.uiuc.edu -- University of Illinois at Urbana-Champaign
-