/tmp

[Dan Stromberg <strombrg () NIS ACS UCI EDU>]

Two possibilities, which perhaps could be implemented as alternatives
on the same system:

1) Provide a library function, perhaps mkztemp(), which creates
/tmp/secz/username/templateXXXXXX.  /tmp/secz is forced 1777 at boot
time.  Pass back the filename and a file handle.  Use of
/tmp/secz/username instead of /tmp/username helps reduce accidental
collisions, but does nothing to prevent intentional DOS.  This one
should return the uid of the user owning the /tmp/secz/username file,
if there's a DOS.

2) Provide a library function, perhaps mkytemp(), which calls a setuid
root program that creates /tmp/secy/username/templateXXXXXX.
/tmp/secy is only writable by root, and mkdir'd at system boot time.
Pass back the filename and a file handle.  The setuid program should
eliminate the DOS, but is slower (exec's hurt).  You could just use
/sec or /stmp, but then temp scrubbers have to be modified slightly,
slowing migration.

I believe #2 would be the standard choice, while #1 would be reserved
for situations requiring a LOT of temp files in a short interval.  Or
perhaps #1 should be published on the net, but not included in
libraries, so the path of least resistance is to use the more secure
#2, which would hopefully find its way into libraries.

The setuid program would of course need to be minimalist.

#1 is perhaps related to mkdtemp() on *bsd.  Their man page doesn't
really appear to say what it does.

The effects of setuid programs need to be considered.  Perhaps setuid
programs, both root and nonroot, would use the real username, not the
effective or saved.  Sadly, I suppose this would mean setuid nonroot
programs would have to setuid(geteuid()) prior to mkytemp(), making it
an even less drop-in change.

Comments are desired.  After the suggestion has been through the
shredder, I might implement them.

-- 
Dan Stromberg                                               UCI/NACS/DCS

Attachment: _bin
Description: