/tmp system shortcomings

Kill9 (kill9@SUCCEED.NET)
Sun, 08 Mar 1998 10:02:59 -0800

> All this complexity of trivial things (just open a temp file) is one
> of the reasons I think the whole idea of /tmp is a fundamental
> misdesign and eventually one should be able to chmod it to 755 (while
> programs should use per-user TMPDIRs).

Maybe I'm a little off this morning, but even per-user TMPDIR's aren't a
very good solution. So you make a tmp directory somewhere for each user
(technically I don't think it matters where) and set the directory
permissions so that only that user has read/write/execute. Yes, that will
stop other users from creating symlinks and such and waiting to trap
innocent users.

But,

If all the programs Joe user runs now creates files in /usr/home/joe/tmp and
one of the programs is suid root and is vulnerable to a symlink attack then
no other users can abuse that program... except Joe. Joe can still symlink
attack programs because he controls all the files in his tmp directory. I
suppose he could even do a pipe attack against himself (as described in the
gcc post earlier), but for that to be worth while it would have to be a
suid program thinking it was a trusted pipe it was reading trusted data
from...anyway

If programs create files in their effective user id tmp space (ie Joe runs a
suid root program so it creates files in /root/tmp)
then Joe couldn't abuse the symlinks, but now we are forcing programs to
open and write to files as root, rather than at least trying to convince
authors to give away permissions and open and write as the user. I think
this would be a very bad thing.

Perhaps there should be a new Temp Filesystem that creates temp files off in
an untouchable area like the proc filesystem. Only programs that call
mktemp get a filehandle in there, no symlinks allowed. Of course, this would
have to be handled at the kernel level... but done properly it could
eliminate a gob of poorly written code.

Pro's con's caveats?

Kill9

(ducking for cover)