Xref: utzoo comp.unix.wizards:25626 alt.security:2540
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!execu!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F Haugh II)
Newsgroups: comp.unix.wizards,alt.security
Subject: Re: BSD tty security, part 3: How to Fix It
Message-ID: <19276@rpp386.cactus.org>
Date: 15 May 91 14:02:10 GMT
References: <19262@rpp386.cactus.org> <10581:May1315:01:2891@kramden.acf.nyu.edu> <19270@rpp386.cactus.org> <25833:May1416:43:4291@kramden.acf.nyu.edu>
Reply-To: jfh@rpp386.cactus.org (John F Haugh II)
Organization: Lone Star Cat Emporium and BBQ Grill
Lines: 45
X-Clever-Slogan: Help Prevent Robbery.  Tax the IRS.

In article <25833:May1416:43:4291@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>Okay, now I understand what you're getting at. The answer is that passwd
>doesn't know who it's talking to. If a user wants to run it in a
>situation where every keystroke could be monitored---e.g., over an
>Ethernet---you can't realistically say that passwd should refuse to
>function. Or are you going to restrict use of passwd to people who can
>walk up to the console? (In a few environments this is reasonable.)

Glad you finally got that point.

Now, given that passwd can't verify who it is talking to, how can it
possibly meet the assurances required to state that it isn't talking
to a trojan horse?

>Eavesdropping (and data corruption) is no worse a problem for passwd
>than it is for any user program. If you want to solve those essentially
>physical problems, encrypt your data.

Sure.  But I'm not even talking about eavesdropping, I'm talking
about really simple stuff, like trojan horses.  What about a case
where my application looks just like "passwd", but is really just
a pipe or somesuch (like the "pty" command) from your keyboard to
the real passwd command.

>Sure it does. Please read suggestion #24.

I log in as "jfh", and start my trojan horse.  It displays a login
banner.  You type "brnstnd".  I prompt for your passwd.  You enter
it.  I stuff the username and password in a file and exit.  What
does your scheme do to prevent that from happening on a hardwired
terminal?

>> As for using
>> different SAK keys, what to do about UUCP, etc?
>
>This is a non-issue.

It just goes to show that you've never bothered thinking about what
the issues are.  How exactly would an application turn off the SAK
key under your system?
-- 
John F. Haugh II        | Distribution to  | UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) |  Domain: jfh@rpp386.cactus.org
"If liberals interpreted the 2nd Amendment the same way they interpret the
 rest of the Constitution, gun ownership would be mandatory."