Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!mips!apple!well!nagle From: nagle@well.sf.ca.us (John Nagle) Newsgroups: comp.unix.internals Subject: Re: Finding Passwords Message-ID: <20849@well.sf.ca.us> Date: 30 Sep 90 17:20:16 GMT References: <3346:Sep2422:01:3090@kramden.acf.nyu. <936@mwtech.UUCP> <25680:Sep2805:58:2290@kramden.acf.nyu.edu> Lines: 21 The "trusted path" approach, as in ULTRIX, is the way to go, but it does present problems in the presence of dial-up lines, port selectors, and such. We used it in KSOS (a late 70s vintage high-security UNIX-like system), but that system was for environments where all terminals were hard-wired. We had two paths to the terminal, switched in the kernel. The main path was used for all user programs. The trusted path was used only by the "secure initiator", which handled logins and other security-related functions. Pushing "break" switched the terminal to the trusted path, and the terminal stayed on the trusted path until the secure initiator (a privileged application program) made a system call to switch it back. The user could push break at any time to force this switch, and there was no way a user program could prevent it. You can't do it in "getty"; it has to be in the kernel. There must be something the user can (and must) do that can't be intercepted by any user program. John Nagle