BSD tty security, part 4: What You Can Look Forward To

[John F Haugh II]

In article <14768 at ulysses.att.com> smb at ulysses.att.com (Steven Bellovin) writes:
>                                                          John Haugh's
>suggestion of a secure attention key tends to beg the point -- one can
>specify one, but there's still the problem of how you implement it.

I don't think this is even a problem.  This issue with SAK implementation
seems to be a trade-off between knowing it will always work, and wanting
it to always work.  The issue seems to be solved by having fixed-baud
ports use fixed-key sequences that are unlikely to occur in real life,
and having variable-baud ports use baud rate independent sequences
(such as framing errors, hence Dan's <BREAK> key suggestion).  If you
allow it to always work, you have the problem I pointed out in the
discussion with Dan - what do you do when something mimics the <BREAK>
key, such as a framing error condition on a serial port.  If you allow
just anyone to turn it off, you get no assurance that whacking the SAK
key really got you on the trusted path.  Thus there is a struggle
between security and usablity ...

>It's still hard to revoke all access to an open tty, especially given
>the indirect accesses through /dev/tty.  (Obviously it can be done
>without the session manager, since several vendors have done it.  I
>haven't examined any of these in detail, so I don't know how reliable
>their solutions are.)  I'm *not* prepared to offer my own retrofit
>solution at this time.

I wouldn't say it is "hard", simply as part of the nature of the beast,
but rather it is "hard" because the information isn't collected in
the right places (which you seem to allude to).  There is no mapping
from inode to process, and there is no easy collection of u_ttyd's
all in one nice place.  Fix those two problems, and the issue should
evaporate.

I do know that AT&T has managed to solve the problems with access
revocation since their new MLS product is either been evaluated at B2
or is heading that way (their original MLS has already been through
formal at B1).  For IBM's current offering, AIX v3 has revoke()
and frevoke() system calls which provide for all the needed assurance
that you have a clean line, when combined with fchown() and fchmod().

As for "how reliable they are", in the case of the former, the NCSC
has blessed it, and in the later, one customer found the notion of
clean ports disgusting enough (I made sure the login port was really,
really clean ;-) that we were forced to take out the code that made
scrubbing the port prior to login mandatory.  But it is very possible
under Sys5/MLS and AIX v3 to get completely clean ports, without the
changes Dan suggests are required.  I know that the IBM, Apple, Sun,
and SCO UNIX (as well as IBM's old Trusted XENIX) products all provide
assurances that what you are talking is really what you think you are
talking to, and that no one else has access to it.  That is just the
partial list ...
-- 
John F. Haugh II        | Distribution to  | UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) |  Domain: jfh at rpp386.cactus.org
"If liberals interpreted the 2nd Amendment the same way they interpret the
 rest of the Constitution, gun ownership would be mandatory."