Xref: utzoo comp.unix.internals:2839 alt.security:2570 Path: utzoo!utgpu!cs.utexas.edu!natinst!sequoia!rpp386!jfh From: jfh@rpp386.cactus.org (John F Haugh II) Newsgroups: comp.unix.internals,alt.security Subject: Re: BSD tty security, part 3: How to Fix It Message-ID: <19309@rpp386.cactus.org> Date: 18 May 91 19:33:18 GMT References: <19270@rpp386.cactus.org> <25833:May1416:43:4291@kramden.acf.nyu.edu> <3136@cirrusl.UUCP> <19306@rpp386.cactus.org> <3140@cirrusl.UUCP> Reply-To: jfh@rpp386.cactus.org (John F Haugh II) Organization: Lone Star Cat Emporium and BBQ Grill Lines: 50 X-Clever-Slogan: Help Prevent Robbery. Tax the IRS. In article <3140@cirrusl.UUCP> Rahul Dhesi writes: >Dan will, of course, have his own response to this (as he always >does :-). Yes, I have read the specification for the Dan Bernstein Window Manager. It argues with your for 15 minutes and still doesn't resize the window ... > Although it's true that not all hardware guarantees an >out-of-band channel to support a secure attention key, it turns out >that there is a simple method of using in-band signalling that is >*virtually* foolproof. The problem is that it must be =absolutely= foolproof. If I can come up with even one way to circumvent it, it isn't usable as a SAK sequence. AT&T with the SV/MLS product uses DTR as the out-of-band signal. What about three-wire terminals? [ The answer there is that if you don't use exactly the set up the NCSC evaluated, your milage may vary ;-) ] > (1 second pause) +++ (1 second pause) > >When the above happens on the data line, a modem that understands it >goes into command mode. Every second I send an answer-back request to your terminal. Once a second I receive the answer-back, strip it out from whatever you type, and pass that along unchanged to the rest of the system. You never notice anything funny because you aren't talking to the hardware anyhow, but rather my little trojan horse that is pretending to be the login program. It's obvious that you are thinking a lot harder than Dan, but it isn't clear that you understand the nature of the problem. A SAK squence must be absolutely uninteruptable (for lack of a better word). I don't think it is possible for a single SAK sequence to apply to all possible login session types for more than the smallest collection of hardware. I think it takes a multiple choice approach. But SAK alone is not the end-all to security. You also need an application that can do useful things with SAK, and Dan's suggestion that every SAK kills everything on the line is just too gross. If the user can't SAK at any time, they will never SAK. And that means any need for the SAK key during crucial operations (like changing your password) will not be met - what, press SAK and kill my XBIFF? -- 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."