Security Considerations

Security is a complex issue, and this section cannot nearly explain everything that there is to it. We will try to point out the most common situations where your programs need to be concerned about security.

It is very easy to create security holes by incorrectly creating temporary files under /tmp. You must guarantee that the files you will use do not exist at the time of creation. Using an "unpredictable" or "unique" filename is not enough; you must guarantee that a file with that name will not be created by someone else between the time you compute the name and you actually create the file (basically, the attack involves a second party creating a symlink to a file they want to overwrite).

Fortunately, this is easy to do. You can use the following piece of code:

 char *filename;
  int fd;

  do {
    filename = tempnam (NULL, "foo");
    fd = open (filename, O_CREAT | O_EXCL | O_TRUNC
         | O_RDWR, 0600);
          free (filename);
  } while (fd == -1);
      

Remember to free() the filename and close() and unlink() the file after you are done. If you want to use the Standard I/O library, you can use fdopen() to transform the file descriptor into a FILE *, or you can use tmpfile() to do it in one step.

Try not to use fixed-size buffers. Fixed-size buffers for strings are a typical source of exploitable holes that can lead to obscure bugs. If you absolutely must use fixed-size buffers for strings, please use the g_snprintf() function to specify the maximum size of your buffer.

Glib provides the very convenient g_strdup_printf() function, which works just like sprintf() but will automatically allocate a buffer of the correct size. The return value of this function should be released using g_free(). This is often more convenient to use than g_snprintf(), as it does not limit the size of strings that your program can handle.

If you want to concatenate a group of strings together, you can use the g_strconcat() function, which takes a variable-length list of strings and a NULL pointer as the last argument.

Under no circumstance create a GTK+ program that is setuid root. The GTK+ and GNOME libraries are big and complex, and they have not been audited for security. In any case, you would not want to have such a big piece of code be setuid root anyways. It you must absolutely use root privileges for something, write your program so that the user interface is in a normal, non-privileged process and create a helper program that is setuid and performs the 'dangerous' operations. Also, please notify the GNOME development mailing lists about this and request that someone perform a security audit on your helper program.

In general, if you are not sure that something may create a security risk, please ask on the GNOME development mailing lists about it.

You can read more about some security issues that you might find while programming Unix applications in Wietse Venema's Murphy's law and computer security. There are other security papers in that site that you might find interesting.