Re: [Texmacs-dev] Secure creation of temporary files

[Joris van der Hoeven]

> The discussion on the bug tracker is really of general interest (to
> developers) so I think we should better have it here.
> 
> The point is: texmacs currently uses tmpname to create temporary
> files. This function returns an unusued file name in /tmp, a temporary
> file is later created with that name. It is recommanded to use tmpfile
> instead to atomically create a temporary file. Files created by
> tmpfile are deleted when the file is closed.
> 
> The problem with that is texmacs use temporary file names as output
> file name in shell scripts executed by the 'system' command. According
> to Igor, since tmpfile returns a FILE handle, the file name is
> accessible so that should not be a problem, but Joris seems
> uncomfortable about that (maybe I overlooked something).

Yes, but how do you suggest to write the equivalent of the current
function 'get_temp_file_name'? Would it be possible to do the following:

  * Call tmpfile or mkstemp (returns a file handle to an opened file).
  * Retrieve the name of the returned file handle.
  * Close the returned file.
  * Return the name.

What bothers me is that the temporary file will be opened a second
time with this solution, but maybe this doesn't matter...

In other words, what I really want is to retrieve only a file name,
without doing operations on the file.

> Another way to work around tmp file name vulnerability would be to
> create files in user-only accessible directory (say ~/.TeXmacs/tmp)
> with appropriate privileges. That is secure as long as the software is
> not setuid. Otherwise a malicious program (unknowingly) run by the
> user could try to exploit the vulnerability. However no one should
> ever run TeXmacs as root. However experience shows that some people
> actually do that :-(

I think that it would be good to use 'mkstemp' to create temporary
files in ~/.TeXmacs/system/tmp anyway.

> Additionnaly creating tmp files in ~/.TeXmacs/tmp is not such a good
> thing because it defeats automatic cleanup of /tmp and can quickly
> increase the entropy of the /home file system, which is generally used
> for long-lasting files.

Maybe, but we usually remove temporary files immediately after usage.

> Here is a related discussion (I just saw it was relevant, I do not
> actually took the time to understand what is was about):
> 
> http://lwn.net/1998/0312/newtmp.html
> 
> Also here is an example exploit for an old gcc vulnerability.
> 
> http://lwn.net/1998/0226/symlink.html
> 
> Generally tmp exploits use the race condition created by the time
> between the moment when the file name is computed (and known to be
> unused) and when it is actually used (and no longer garanteed to be
> unused). This race condition is made easier to exploit when the file
> name is easy to guess, which happens when most free chars in the name
> are taken by the PID of the creating process.
> 
> The following message give simple and practical rules of thumb to /tmp
> safety.
> 
> http://lwn.net/2000/1221/a/sec-tmp.php3
> 
> However, note that this message does not mention tmpfile which is more
> portable and seems more versatile than mkstemp and mkdtemp.

In fact, it might be that 'mkdtemp' is best for our purpose,
because it does not open any file.

> Bottom line: what is the problem with tmpfile?

The same as with mkstemp: how to retrieve only a file name,
without doing operations on the file.