openstack team mailing list archive

["Daniel P. Berrange" <berrange@xxxxxxxxxx>]

On Mon, Jul 02, 2012 at 08:17:08AM -0700, Johannes Erdfelt wrote:
> On Mon, Jul 02, 2012, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote:
> > In Fedora 18, /tmp is going to be a RAM filesystem, so we absolutely
> > must not create any sizeable files on /tmp.
> > 
> > In addition from a security POV, we must aim to *never* use /tmp for
> > anything at all
> > 
> >   http://danwalsh.livejournal.com/11467.html
> 
> I take exception to that. Saying *never* is incorrect.
> 
> You (and that blog post) say that we should *never* use /tmp for
> security reasons, but don't go on to explain why using mkstemp or
> mkdtemp is a security problem.
> 
> Even the glibc documentation says they are safe wrt to security issues:
> 
> http://www.gnu.org/software/libc/manual/html_node/Temporary-Files.html

NB, I never said that mkstemp/mkdtemp are unsafe. I that that
in general usage of /tmp is a bad idea. It is possible to use
/tmp safely, but historical security records across the entire
software industry shows that developers routinely screw up with
their use of /tmp. Since /tmp is a globally accessible directory,
the consequences of such screw ups can be very severe. The globally
writable nature of /tmp also makes it hard for mandatory access
control systems like SELinux / AppArmour to ensure that a daemon's
temporary files are protected against these screw ups.

As the blog post says, /tmp is a reasonable place for end users
to have temporary files. Daemons needing somewhat to create
their own private temporary files should use a private directory
location accessible only to themslves, so that in the event of
a screw up the damage is mor elimit limited. There are very few
compelling reasons why something like Nova should ever need to
use a globally writable directory for its temp files / directories.

> > It would be good to do a thorough audit of the code to make sure
> > nothing is using the tmpfile functions without explicitly specifying
> > a directory path that is private to the OpenStack daemon in question.
> 
> Not using /tmp for large files is a good reason for practical reasons
> (distributions moving to ramfs for /tmp).
> 
> But please don't start throwing around warnings that all uses of /tmp
> are a security risk without backing that up.

I stand by my point that in general usage of /tmp is a risk because
for every experianced developer who can get things right, there are
hordes of others who get it wrong & eventually one such bug will
slip through the review net. Since there are rarely compelling reasons
for the use of /tmp, avoiding it by default is a good defensive choice.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|