Xref: utzoo comp.unix.wizards:25682 alt.security:2579
Path: utzoo!utgpu!cs.utexas.edu!natinst!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F Haugh II)
Newsgroups: comp.unix.wizards,alt.security
Subject: Re: BSD tty security, part 4: What You Can Look Forward To
Message-ID: <19315@rpp386.cactus.org>
Date: 19 May 91 22:25:04 GMT
References: <19271@rpp386.cactus.org> <1775:May1420:06:1291@kramden.acf.nyu.edu> <19280@rpp386.cactus.org> <29167:May1918:13:2991@kramden.acf.nyu.edu>
Reply-To: jfh@rpp386.cactus.org (John F Haugh II)
Organization: Lone Star Cat Emporium and BBQ Grill
Lines: 56
X-Clever-Slogan: Help Prevent Robbery.  Tax the IRS.

In article <29167:May1918:13:2991@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>BSD 4.2- and 4.3-derived systems have a ``revoke'' concept (viz.,
>vhangup()) and have huge problems with the tty system. So much for that
>suspicion.

Then they obviously did it incorrectly.  UNIX also has the concept
of access right restrictions implemented via the iaccess() kernel
service.  If it had a bug allowing "jfh" to read and write any
files owned by "root", it wouldn't disprove the concept of file
access permissions.  It would merely prove that the implementors
of BSD didn't get vhangup() correct (if you want to claim its
purpose is really to completely clean a line, that is).

>The very latest version of BSD has a revoke() syscall which works just
>like you said. It still lets anyone take over a ``script'' session.

This has =nothing= to do with the discussion.  1). Does the revoke
system call work?  2). Does the system protect the cleaned port from
intrusion?  If 1) and 2) are both true, and you can still take over
the "script" session, I'll eat my shorts.  Unless the revoke() system
call removes all access to the port, and unless the system changes
the access modes of the cleaned tty line to deny future attempts at
accessing the system, there is no guarantee the line is protected.

>Face it, John: revoke() does not solve any problems that avoiding a used
>tty entirely doesn't solve. The most revoke() can do is guarantee that
>the tty used for login is clean, and that's exactly what my proposals
>do. Stop pretending that there's some advantage to revoke().

Sure there are.  "Denial of service".  If I manage to take up all
the pty's, how are you ever going to get me off the port?

Besides, the point about revoke() isn't to keep you from using a
tty that is =in= use, but rather to get a program that has no
business using the port off the port in the first place.  That could
be anything - including killing jobs that attached themselves to
your port =after= you logged in.  How do you get a job that has
gained read/write access to your login port off of your login port
once it is on there?

>A Trojan Horse is ineffective unless it actually gets a chance to talk
>to someone. Under my suggestions, a normal user logging in will always
>be talking directly to a system process. No other processes can access
>the line. There's no reason to ``get rid of'' what you can just ignore.

I don't care what happens when you login.  I want to know what happens
=after= you login.  Get it through you think skull.  I don't care about
login time.  F*ck login time.  What happens 15 or 20 minutes later when
some proceess some how gets on your port and starts doing things to it?
How does the Dan Bernstein Trusted Path Manager get that process off
the line, other than arguing with it for 2 weeks before doing nothing?
-- 
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."