BSD tty security, part 3: How to Fix It

[John F Haugh II]

In article <14021:May1521:56:2291 at kramden.acf.nyu.edu> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
>In article <19276 at rpp386.cactus.org> jfh at 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 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."