Xref: utzoo comp.unix.wizards:25597 alt.security:2529 Path: utzoo!utgpu!news-server.csri.toronto.edu!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: <19271@rpp386.cactus.org> Date: 14 May 91 14:18:47 GMT References: <1991Apr30.164646.11693@pcserver2.naitc.com> <721@seqp4.UUCP> <729@seqp4.UUCP> <14768@ulysses.att.com> Reply-To: jfh@rpp386.cactus.org (John F Haugh II) Organization: Lone Star Cat Emporium and BBQ Grill Lines: 55 X-Clever-Slogan: Help Prevent Robbery. Tax the IRS. In article <14768@ulysses.att.com> smb@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 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 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@rpp386.cactus.org "If liberals interpreted the 2nd Amendment the same way they interpret the rest of the Constitution, gun ownership would be mandatory."