On Mon, Jul 02, 2012 at 08:17:08AM -0700, Johannes Erdfelt wrote: > On Mon, Jul 02, 2012, Daniel P. Berrange <berra...@redhat.com> 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 :| _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
