Secure temporary files in Linux (ZDNet India)

Why security problems does it solve to mount /tmp as nosuid,noexec,nodev? This is more
restrictive, but is it needlessly so rather than more secure?  The 'nodev' option is
meaningless, because only root may create device nodes and if one is root, then remounting
/tmp without the nodev option is not a problem.  'nosuid' is redundant if 'noexec' is
specified.  Why 'noexec'?  How does it in any way enhance the security of the system to
prevent a user from running an application in /tmp if the user can just run it out of their
home directory instead? 

The article mentions the fact that it is often possible for users to read each other's files
in /tmp (an issue with umask and individual applications, rather than with /tmp.)  But the
suggested solution doesn't address this issue at all.

The article suggests that users may create a private directory for temporary files mounted as
a loopback device if they don't have sufficient privileges to make changes to /tmp.  What is
the point of that?  Most people aren't interested in imposing additional restrictions only on
themselves.  Any application the user runs can easily bypass this anyway (e.g. create a new
loopback mount of the same file or remount the loopback with different options.)  Or just
write the temp files to /tmp instead of the user's personal temporary directory.  

Reading the comments first, I expected the article to be much worse than 
it was.  Yes it's not complete, but it was written as a 1 tricky pony not 
everything you would ever need to know about /tmp but were too afraid to 
ask.

The basis for seperate /tmp and restrictive mount options, is the 
principal of least privilege.  The service daemons frequently are run with 
their own user ID and without write permission on any directories, so 
someone finding a way to run a command, is very likely looking for 
somewhere to upload code as a step towards privilege escalation.

Those suggesting it's pointless to take security measures, because they 
can ultimately be circumvented aren't looking at the practicalities of 
your typical attack.

Soft targets are hit, hardened systems are too time consuming, and limit 
the damage doable before detection and counter measures.  Only a complete 
optimist believes their system is un-crackable.

As for differences between /var/tmp and /tmp, it's something I wish 
application developers would make use of.  KDE likes to spend time 
creating per-user semi-temporary sockets, so the gain of using TMPFS 
for /tmp is reduced by relatively slow time to rebuild cleaned out stuff 
in /tmp.

This is actually quite amusing.  For one, I never wrote this for ZDNet Asia.  The original is
for 
TechRepublic: http://blogs.techrepublic.com.com/opensource/?p=171

It's also not an all-or-nothing solution, but part of an overall solution (you know... the
little pieces).  
To think that securing /tmp is all you can do is laughable.  But it's a valid part... it's
called defense 
in depth.

Likewise, the unfortunate thing for writing these tips is that they have restrictive word
counts so 
while I could have written a lot more info, the space constraints are actually quite small so
if 
something could use, say, 1000 words, I've got to cram it into 400, which makes things
challenging 
and doesn't leave much room for lots of explanation.

I suppose a disclaimer might have been useful... something along the lines of "if you think
this is all 
you need to do to secure your system, you're an idiot", but somehow I don't think my editor
would 
have liked that.