BSD tty security, part 2: The POSIX Perspective

[Dan Bernstein]

[Warning: By the end of part 1 you may have thought I was in a good
mood. Sorry, but no more Mr. Nice Guy. I will return to sweetness,
charm, and light in part 3.]

One of the security holes mentioned in part 1 (any user being able to
log any other user out) was a deeply buried bug in Berkeley's
implementation of a new POSIX requirement. This is a good example of how
additional security channels (viz., POSIX sessions) make the system much
more fragile. One of the virtues of the original UNIX system was that
all security went through a single channel, namely the uid. Why can't we
stick to this model?

Popular BSD-derived POSIX systems like Ultrix 4.1, SunOS 4.1, and Convex
UNIX 9.0 are completely insecure: any user can take complete control of
any other user's session, with no privileges, no warning, no visible
effect if the attacker is careful, and no logs after the fact.

I asked Marc Teitelbaum how POSIX (particularly POSIX sessions) helped
tty security in the latest BSD 4.3. He pointed to revoke(), but revoke()
only helps security because it is applied at the *beginning* of a
session, and this is not required or even hinted at by POSIX. He
couldn't find another answer. I can still take full control of any
session begun by script or screen or emacs or expect.

As those of you involved with POSIX know, any process can send SIGCONT
to any other process in the same session, dodging all the restrictions
of normal security and job control. Believe it or not, SIGSTOP and
SIGCONT used to be a valuable synchronization technique, even for
privileged applications. Now they're useless. This can only be regarded
as a security hole.

Is it unreasonable to conclude that POSIX sessions do not help security?
That, in fact, they hurt security, by forcing changes upon a quite
fragile piece of the system?

It gets worse. In comp.unix.* we've seen repeated complaints that POSIX
breaks popular applications. No, I'm not even talking about pty. I'm
talking about screen, and expect, and emacs. These programs want to
control children running under a different terminal, but POSIX simply
doesn't acknowledge that people *want* cross-session job control. It
invented ``orphaned process groups''---yet another ``standard'' which
has never shown benefits and which breaks applications left and right.

Is it unreasonable to conclude that POSIX sessions are a problem?

I keep asking people what POSIX sessions do for users, or programmers,
or administrators, or system implementors. Nobody comes up with an
answer. ``They were meant to make job control secure,'' people say. So
why tf are they required even on systems not supporting the job control
option?

After all this I'm not even going to say POSIX sessions should be
abolished. All I want is for them to be made optional, like job control.
It really wouldn't be difficult---just change a couple of definitions
and put the equivalent of #ifdef SESSION around the dozens of additional
rules invented for POSIX sessions. Is this such a price to pay for
backward compatibility, extra security, and the chance to make POSIX
improve over the years as people figure out simpler job control models?
And doesn't it make sense that inventions in a standard should be
optional to begin with?

Let me close these comments with a personal remark: The next time I
report tty security holes to a vendor, if I hear ``We've fixed that,
we support POSIX,'' I'm probably going to do something violent. Maybe
it'll just be a symbolic burning of the latest POSIX 1003.1 in the
middle of Central Park, but I know it's gonna be violent. :-)

---Dan