Xref: utzoo comp.unix.wizards:24624 alt.security:2052
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!snorkelwacker.mit.edu!hsdndev!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.wizards,alt.security
Subject: Re: POSIX bashing
Message-ID: <6435:Apr116:06:0291@kramden.acf.nyu.edu>
Date: 1 Apr 91 16:06:02 GMT
Article-I.D.: kramden.6435:Apr116:06:0291
References: <1991Mar30.202637.8629@kithrup.COM> <4269:Apr105:57:0091@kramden.acf.nyu.edu> <1991Apr01.083503.27317@kithrup.COM>
Organization: IR
Lines: 68

In article <1991Apr01.083503.27317@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes:
> In article <4269:Apr105:57:0091@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> >Idiotic. Absolutely idiotic. UNIX has always worked on the principle
> >that if you have permission to open a file, you can open it, and use the
> >descriptor forever. *Normal file access permissions handle security*.
> So.  I start a pty session, that means I can send any arbitrary signal to
> any process on the slave side?  Gee, that doesn't sound right.

Of course you can send a signal to a process on the slave side, provided
you're the owner of that process. TIOCSIG is a separate abomination.

> Please tell me, for example, why a different process group should be able to
> change the pgrp associated with *my* tty?

If a tty is in the filesystem, and it is writable to you, and accessing
the tty for writing lets you change its pgrp, then you can change its
pgrp. Why? Because that's normal UNIX security.

The problem with the current BSD + POSIX setup is that you can go beyond
the file permissions.

> >Not so. On every available BSD-based system---including Convex UNIX 9.0
> >and mainstream systems like SunOS and Ultrix---I can gain invisible
> >write and TIOCSTI access to any tty, with a short program and no
> >privileges. 
> Several people have commented that TIOCSTI is an abomination that should be
> forgotten.  Neither SCO nor POSIX have it.

Under SunOS and Ultrix, at least, I can also get *read* access, though
this involves some race conditions. But write access is already a huge
security violation.

> >On the flip side, if you have enough interest in security to want to
> >eliminate the holes, I'm perfectly willing to tell you how. 
> I think I asked you about your objections to POSIX, about a year ago, and
> you just complained that it broke things.  Nothing about security.

You only asked for examples. Yes, my biggest complaint about POSIX is
that in many cases it preserves *neither* the System V *nor* the BSD
semantics. Instead it invents new, more complex semantics, with
rationales as convincing as ``tty security'' (which they have failed to
achieve).

Did you know that the POSIX definition of ``background process'' does
not agree with the BSD definition? So where does it come from? Why is it
useful? There's *nothing* in the rationale to justify this change.

> >> I found this in emacs,
> >> incidently.
> >The POSIX folks don't even understand backwards compatibility. Shameful.
> Gee, they broke some SysV'isms, yet I bet you don't complain about that.

I'm not familiar enough with System V to see where POSIX made silent
changes. I can see some spots where POSIX changed from the System V
behavior to the BSD behavior, and usually they tried to preserve the
original semantics as a special case. If you show me some System V
applications that break as badly as emacs, screen, atty, et al. under
BSD + POSIX, I'll be glad to complain about them.

However, tty security is a much more important problem right now for the
real world, POSIX aside. I'll bet that your system hasn't closed any of
the System V tty security holes that Steve Bellovin pointed out years
ago. The latest I heard from Berkeley indicates that BSD 4.4 ttys will
be just as insecure as BSD 4.3 ttys.

WHY SHOULD EVERY SINGLE AVAILABLE BSD SYSTEM LET ANYONE BECOME ROOT?

---Dan