Re: Race conditions

[lm () melb cpr itg telecom com au (Luke Mewburn)]

> How does one code a suid program so that it evades these problems with
> symlink race conditions?  Is there a way to atomically check if a file
> is a symlink and open it, or is there another stratedgy?

I was investigating this a while ago (because I thought I found a
potential race in the 4.4BSD mail.local.c; it may still be there
except that to exploit it you need write perms in /var/mail)

After checking the man pages in Solaris 2.x and NetBSD, and confirming
it in NetBSD by checking the kernel sources, I discovered an interesting
fact: when using open(), with flags of O_EXCL and O_CREAT, the following
condition holds true:
        If O_EXCL is set and the last component of the pathname
        is a symbolic link, open() will fail even if the symbolic
        link points to a non-existant name.

So this can be used to ensure that people can't exploit the race
condition where you symlink to a non-existant file and get it created
for you, since open() is effectively testing this atomically for you.

Unfortunately, it appears that older systems (possibly including SunOS 4
and Ultrix) don't have this check.


In many cases, the race condition is in creating a new file as a priviliged
user in a directory where unpriviliged users can create files/symlinks
(e.g, 1777 /var/spool/mail.) If the directory has such permissions,
shouldn't the appropriate method be to seteuid(target_user) before
creating the file?
If restricted directories (755 /var/mail) are used, the race condition
can't be exploited, but root perms should only be used for the initial
file creation; once the file is there and owned by the user, switching
to their uid to complete the work should be safe, correct?

--
Luke Mewburn                                                  <lm () werj com au>
``Think of it as Evolution in Action''
    -- 'Oath of Fealty', Niven & Pournelle