|
If I may, both bastille and libpam-temp allow something similar for
`real users` ($TMP pointing to a temporary directory inside a user's
home) but /tmp is used more often by programs, cron (or other automation software, which would require trwxrwxrwx permissions and or doesn't use) in a directory /tmp is also used for file uploads in many web hosting systems (I put /tmp in a seperate filesystems just so I can put noexec on it, not to control space, which usually is a major pain) Also, anonymous ftp incoming usually "tries" to make sure users cannot read what is uploaded(only an admin can do that, theoretically) I'd consider exec flags on /tmp only if it was 0700 or 0000(which would negate the exec flags anyway, and might break software) (I normally mount /var/tmp and /usr/tmp using the bind mount options on top of the newly "somewhat a little more secure" /tmp) Does the lsb have anything to say about permissions for /tmp ? or mount flags for that matter? I think what Microsoft did and Debian didn't (yet?), was say "do not put temporary files for all applications using the hack of the +t(sticky flag) under /tmp in a shared directory, as that's not the debian way" :) P.S. I know that if users can upload arbitrary cgi's it's already not as secure as it could be What I'm trying to avoid is a remote non-root exploit allowing an attacker to put a binary in /tmp, which exploits a local root exploit, and roots the box. This precaution I try to use on all unix derivatives I work on(mostly Solaris, Debian, Redhat right now) Defense in depth, like all chains, starts at the weakest link... Jim Popovitch wrote:
|