Path: utzoo!attcan!uunet!clyde.concordia.ca!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.internals
Subject: Re: Finding Passwords
Message-ID: <9215:Oct910:27:3190@kramden.acf.nyu.edu>
Date: 9 Oct 90 10:27:31 GMT
References: <BZS.90Oct6191703@world.std.com> <1990Oct7.155203.13283@hq.demos.su> <1849@necisa.ho.necisa.oz>
Organization: IR
Lines: 31

In article <1849@necisa.ho.necisa.oz> boyd@necisa.ho.necisa.oz (Boyd Roberts) writes:
> The semantics are always wrong and your 20 line `hack' may well turn out
> to be a serious problem.  Think about the problem.  Solve the problem.
> Code the algorithm.  Because it's simple and `cheap' doesn't mean it's right.

Good advice...

The problem is to always be able to cut off any middlemen, specifically
on a physical tty (really modem) line.

There's no good way under UNIX to enforce new access permissions on an
object. Once a program is talking to the tty, it has it, forever. Rather
than kludging a wimpy vhan---uh, rather than half-as---uh, let's assume
that there's no way to get around this.

This means that the processes can't be talking to the modem device
directly. There has to be an extra level of indirection. Processes are
grouped within a ``session,'' which may or may not be associated with a
``connection'' to the outside world. The connection between the session
and the modem is controlled by a system program, which drops the
connection when it receives a BREAK.

That's it! The Trojan Horse problem is basically solved.

For full details on how this might be made to work in practice, read
Steve Bellovin's excellent session management paper, available from
inet.att.com as dist/sessext.ps. If you want a real, working BSD program
that implements these security features right now, just ... whoops,
promised myself I wouldn't mention it this time. [grin]

---Dan