brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (04/25/91)
[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