Xref: utzoo comp.unix.wizards:25525 alt.security:2507
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!sdd.hp.com!cs.utexas.edu!chinacat!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: <19253@rpp386.cactus.org>
Date: 10 May 91 12:12:44 GMT
References: <19002@sdcc6.ucsd.edu> <17790:May522:37:5591@kramden.acf.nyu.edu> <19249@rpp386.cactus.org> <28949:May620:55:5391@kramden.acf.nyu.edu>
Reply-To: jfh@rpp386.cactus.org (John F Haugh II)
Organization: Lone Star Cat Emporium and BBQ Grill
Lines: 61
X-Clever-Slogan: Help Prevent Robbery.  Tax the IRS.

In article <28949:May620:55:5391@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>Agreed. Since UNIX doesn't provide for revoking a valid file descriptor,
>the obvious solution is to make sure that no user program ever gets to
>touch a modem driver. A privileged program can control the driver and
>route I/O through a pipe or pseudo-tty or socket or any other basically
>dynamic object. It can also drop its control of the driver whenever the
>user types break.

No, the obvious solution is to provide for file access revocation.  What
do you do to assure (because, remember, we have to provide assurances
that our solution really works - handwaving doesn't cut it) that there
isn't some process on the other side of the "privileged program" that
is reading our hardware tty?  Under all the suggestions I've seen for
this hack, there is still a hardware tty device whose privilege bits
we must very carefully watch out for lest anyone ever get access to it.

>The problem is that, once again, UNIX doesn't have this concept of
>terminating current access. The last time that people tried to add it to
>BSD was vhangup(), and that was a complete failure.

Then fix vhangup().

>I find it conceptually much simpler to just make sure that unprivileged
>programs never open /dev/modem*.

I find it conceptually much simpler to not have one extra process per
active tty port.

>Well, sure, but that's even more work that Muller hasn't outlined in
>detail. Again it seems much simpler to put this control at the user
>level.

Well, I have a real job.  I'd love to wander about the Reno sources
I've got laying around and make the fixes, but I've got other things
that those people that sign my checks keep telling me are more
important ...

>C'mon, that's not at the same level of detail as ``Make /dev/tty ioctls
>work on /dev/tty??''. *What* is the mechanism? You obviously have to
>introduce some new structures or add fields to the old ones; where are
>those fields?
>
>To make this work on current systems you also have to make sure that
>u_ttyd access is tracked. This would require that an entirely separate
>set of kernel routines be changed, and I don't think a whole bunch of
>people would figure this out from your description.

Whenever I come up with a way to bill my employer for hours spent in
USENET consultation, then I'll spend the time and provide the exact
details.

But I will tell you this much - the changes that are required are not
that difficult to make.  Your suggestions are the grossest hack I've
seen to date for solving this problem, and it doesn't even provide
any assurance that it has been solved, while at the same time adding
its own collection of deficiencies.
-- 
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."