Xref: utzoo comp.unix.wizards:25642 alt.security:2549 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 3: How to Fix It Message-ID: <19281@rpp386.cactus.org> Date: 16 May 91 14:32:28 GMT References: <19270@rpp386.cactus.org> <25833:May1416:43:4291@kramden.acf.nyu.edu> <19276@rpp386.cactus.org> <14021:May1521:56:2291@kramden.acf.nyu.edu> Reply-To: jfh@rpp386.cactus.org (John F Haugh II) Organization: Lone Star Cat Emporium and BBQ Grill Lines: 87 X-Clever-Slogan: Help Prevent Robbery. Tax the IRS. In article <14021:May1521:56:2291@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <19276@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: >> Now, given that passwd can't verify who it is talking to, how can it >> possibly meet the assurances required to state that it isn't talking >> to a trojan horse? > >You didn't answer my question. Are you going to restrict use of passwd >to people who can walk up to the console? If not, then you are always >vulnerable to eavesdropping, and it's the user's responsibility, not >passwd's, to make sure that nobody's looking over his shoulder. I got news for you, bud, talking to the console doesn't buy you anything either. Besides, physical security falls outside the scope of software security. All the clever hacks can't keep someone from taking the cover off the machine and removing the disk drives. >Who tf cares? A sane user will never invoke such a pipe. It's not >passwd's responsibility to check that the user is sane. Actually, it is passwd's responsibility to insure that it is talking to the user that is has authenticated. That includes not talking to a trojan horse. >Somehow we're failing to communicate here. My model is that the user >walks up to a console or makes a network connection, then types >something that (as the OS documentation guarantees) sends his future >keystrokes directly to the system and nobody else. If he then types his >username and password, nobody else gets the password. If he then types >passwd and changes his password, nobody else gets the password. > >The problem right now is that there are all these security holes---the >system doesn't guarantee that nobody's looking on. My changes make that >guarantee, at least for the tty subsystem. But your system doesn't do what you claim it does - sure, it prevents someone else from logging out, keeping a /dev/tty file descriptor laying around, and doing what it prevents them from doing. It does not prevent them from having trusted code (the passwd command) from being executed by a trojan horse. How many times a day does the user type this "something that sends his future keystrokes directly to the system and nobody else." >Be serious. The whole point of a SECURE attention key is that it cannot >be violated by unprivileged applications (i.e., things outside the TCB). >And, as Bellovin told you, there's no need for an application to turn >off the SAK---you just make the SAK a variable-length signal if normal >data is fixed-length, and vice versa. This is a non-issue. Can I change my baud rate while waiting for the SAK sequence? Of course there's a need to turn off the SAK key - how long is a UUCP packet this week? Once you permit an application to change any way in which the SAK sequence is processed (variable v. fixed length) or affect its being recognized (baud rates), you no longer have a reliable SAK sequence, and all the SAK warm fuzzies won't make SAK usable. The system itself =must= have a way to insure that you and you alone are out there. Not just "you have a way", but "it has a way" too. Please don't answer that the stty command is going to have to be privileged so you can't change parity or character length or baud rate or whatnot. I'm not saying your entire concept is wrong, or useless or anything, just that you are missing some very crucial parts. SAK alone is not enough, it helps a great deal, but it ignores other entire classes of problems that you are waving off. As for your changes, as Bellovin pointed out, they are overly complex in, what I think he called, "the wrong places." Implementing revoke() and a decent SAK probably shouldn't take more than one or two weeks, and it closes all the real interesting holes. Adding "trusted path" should get rid of the rest of the things affecting tty security. The hardest part to trusted path is figuring out what needs to run on the trusted path. The reason that the NCSC criteria are presented in the fashion they are, is that parts of the criteria are often useless without other parts. SAK without trusted path is just a nice way to kill things when you log in. Trusted path keeps trojan horse from springing up once you logged in, but doesn't let you kill any trojan running off the trusted path. It's the bigger picture you are missing. Like, what good is object reuse if you don't have access control, or vice versa? I have to run - the movers are coming in a few minutes to deliver some furniture and maybe I'll find the Orange Book if I shuffle some of the junk around ... -- 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."