Xref: utzoo comp.unix.wizards:25602 alt.security:2532
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!psuvax1!rutgers!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.wizards,alt.security
Subject: Re: BSD tty security, part 3: How to Fix It
Message-ID: <25833:May1416:43:4291@kramden.acf.nyu.edu>
Date: 14 May 91 16:43:42 GMT
References: <19262@rpp386.cactus.org> <10581:May1315:01:2891@kramden.acf.nyu.edu> <19270@rpp386.cactus.org>
Organization: IR
Lines: 53

In article <19270@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes:
> In article <10581:May1315:01:2891@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> >I don't understand this. Why should the application need such assurance?
> >It's just an unprivileged program.
> OK, how would a privileged application get the assurances it wants that
> the port it is talking to is the real port.  For example, how does
> "passwd" know that it really has the real user,

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.)

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.

> BZZZT.  Wrong answer.  Your scam does nothing to protect against
> applications that start on non-network ports.

Sure it does. Please read suggestion #24.

> >Every new telnet or rlogin or script will skip that pty, so who cares?
> >In the meantime the session will be accounted to you.
> Sure.  And I'll have your password.

Perhaps you missed the first sentence. Every new telnet or rlogin or
script will skip that pty, so who cares? Under suggestion #24, getty
will skip it too. You will never get a password, because no user will
ever be talking to your program while logging in.

> >So use a different secure attention key. The point is that if getty is
> >the only program with a hardwired tty open, then there's no way for user
> >programs to mangle that tty except as getty allows.
> What is the difference between getty having a hardwired port open, and
> clone-of-getty sitting on a pty that you just handed me when I logged in?

No user will ever get his clone ``sitting on a pty that you just handed
me when I logged in'' because the login process will skip all used ptys.
End of argument.

> Or do we throw out all the glass tubes being used today? 

That would be silly. Why would you suggest such a thing?

> As for using
> different SAK keys, what to do about UUCP, etc?

This is a non-issue.

---Dan