Xref: utzoo comp.unix.wizards:25641 alt.security:2548
Path: utzoo!utgpu!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 4: What You Can Look Forward To
Message-ID: <19280@rpp386.cactus.org>
Date: 16 May 91 14:03:59 GMT
References: <729@seqp4.UUCP> <14768@ulysses.att.com> <19271@rpp386.cactus.org> <1775:May1420:06:1291@kramden.acf.nyu.edu>
Reply-To: jfh@rpp386.cactus.org (John F Haugh II)
Organization: Lone Star Cat Emporium and BBQ Grill
Lines: 60
X-Clever-Slogan: Help Prevent Robbery.  Tax the IRS.

In article <1775:May1420:06:1291@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>While this is a good indicator of security, it cannot be considered
>entirely accurate---apparently the ratings are based on tests rather
>than specifications, and one of the NCSC reviewers told me that he
>hadn't heard of the tty security problems (hence couldn't test them).

The test cases are usually fairly exhaustive.  The test suite for
access() on IBM Secure Xenix had something like 1300 different
tests that it performed.  I coded some of the early tests for the
revoke() and frevoke() system call while AIX v3 was in development,
and access via /dev/tty was (as I recall, it's been 2 years now)
one of the things I covered.  I do know that backgrounded processes
die painful deaths; customers weren't too pleased to see their jobs
bite the big one, even when they were launched with nohup and so
on.

Talking about bugs in the specific sense ("do you know about TSTI")
and having your NCSC reviewer stare back out you is not proof that
the Orange Book requirement that the system provide for resource
reuse where all previous, unauthorized accesses to the resource have
been terminated.  Given that object reuse is part of the specification
for a secure system, I'd say you have some misconception about what
the rating for a secure system entails.  That doesn't mean there
aren't bugs, but it certainly doesn't mean that access after logout
isn't one of the criteria that are examined.  AIX v3 originally
handled it by killing every process that was anywheres near a tty
device.  Not exactly a popular approach, but it worked great ;-)

>> As for "how reliable they are", in the case of the former, the NCSC
>> has blessed it,
>
>See above.

See above.  These aren't little programmer weenies who don't know
how UNIX works.  This is why features like access revocation exist
in the first place - think of all the ways you can get access to
a device.  Now think of a way to revoke all those ways.  There are
only so many system calls, it shouldn't be that hard to figure out
which ones affect tty access.

>I don't have firsthand experience with the UNIX products from IBM and
>Apple, but Sun has never successfully closed the tty security holes.
>Comments from others indicate that A/UX is just as insecure. I've only
>been talking about BSD-derived systems so I don't want to discuss SCO in
>detail, but I'm told that it may have similar problems with /dev/tty.

I suspect that every system with some "revoke" concept doesn't have
problems with its tty system.  You scheme, for example, can't insure
the passwd command that it isn't being run as part of a trojan horse.
Mine can.  Waving "physical security" at the problem doesn't free you
of your responsiblity for "software security" either.  This is why
"Trusted Path" and "SAK" and "access revocation" are so much more
useful than "don't ever let anyone talk to the hardwire tty."  What
can you do to prevent the trojan from ever being run, and once it is
running, how can you get rid of it?
-- 
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."