Bugtraq mailing list archives
/tmp system shortcomings
From: kill9 () SUCCEED NET (Kill9)
Date: Sun, 8 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)
Current thread:
- Re: another /tmp race: `perl -e' opens temp file not safely, (continued)
- Re: another /tmp race: `perl -e' opens temp file not safely Theo de Raadt (Mar 08)
- Updated list of crypto and security courses Avi Rubin (Mar 09)
- *sigh* another RH5 /tmp problem Mark A. Spencer (Mar 09)
- Re: *sigh* another RH5 /tmp problem Erik Troan (Mar 10)
- Re: Linux libc5 'bug' in mkstemp(). Andreas Jaeger (Mar 10)
- Linux libc5 'bug' in mkstemp(). Greg Alexander (Mar 09)
- Re: Linux libc5 'bug' in mkstemp(). Casper Dik (Mar 10)
- Plaintext passwords in Chase Online Banking dorqus maximus (Mar 07)
- Re: Plaintext passwords in Chase Online Banking dorqus maximus (Mar 08)
- Re: Perl bugs (was Re: another /tmp race: `perl -e') Chip Salzenberg (Mar 08)
- /tmp system shortcomings Kill9 (Mar 08)