Standards, the kernel, and Postfix [LWN.net]

Standards, the kernel, and Postfix

Posted Aug 21, 2008 14:28 UTC (Thu) by epa (subscriber, #39769) [Link]

Exactly.  The relatively smooth upgrading of software on Unix-like systems is because you can
unlink the old file and create a new file with the same name.  The old one will continue to
exist, with its old data, as long as a process has it open.  If you try to fix the suid binary
problem by forcibly removing a file, or overwriting its contents, then you risk breaking
running code.

(Since writing bytes to a file is not atomic, you could theoretically introduce new security
holes by overwriting the contents of a suid binary.  What if someone runs it halfway through
the update, when it contains a mixture of old and new code?)

One answer would be to move the suid flag out of the inode and put it in the directory entry.
Then you could make as many links to a file as you wanted, but you wouldn't be able to get the
suid magic (unless, of course, you have permission to set the suid bit anyway).  But given the
conservatism of Unix-like systems and the large amount of filesystem code that would have to
change, I can't see this happening soon.

Standards, the kernel, and Postfix

Posted Aug 21, 2008 14:44 UTC (Thu) by rwmj (subscriber, #5474) [Link]

No, package managers should just remove the setuid bit before unlinking the file.

This doesn't affect running programs. It does affect someone who starts to run the program at the moment that the suid bit is removed, but this is already a problem during package upgrades (the file is temporarily removed, so attempts to run it can fail briefly).

It's actually possible that package managers do this correctly already, since this problem is very old and well-known.

Rich.

Standards, the kernel, and Postfix

Posted Aug 21, 2008 18:48 UTC (Thu) by vmole (guest, #111) [Link]

No, package managers should put the file in the proper directory with a unique name (e.g. foo.package_new) with proper permissions and ownership, and then rename(2) the proper name to the unique name. This way there's never a time when '/bin/foo' is anything but the proper old entry or the proper new entry, since rename(2) is atomic. Exisiting users of the file won't see the change - they've got an open descriptor to the old file, which remains on disk until the last open descriptor is closed.

How to replace an executable...

Posted Aug 22, 2008 6:08 UTC (Fri) by faramir (subscriber, #2327) [Link]

There seem to be three issues:

1. Atomic replacement of an executable (by name)
2. Removing permissions from potentially hard linked old copies (by inode)
3. Reporting possible nefarious activities by hard linkers.

I think this sequence deals with them all:

1. Hard link canonical name of old executable to first temporary name.
2. Create new executable with second temporary name and appropriate privs.
3. rename() second temporary name to canonical name (this is atomic).
4. Chown/chmod first temporary name to remove any special privileges, execute bits, etc.
5. stat() first temporary name and report if there is more then one link
(Should be just one from first temporary name at this point).
6. Unlink first temporary name.

At the end of the sequence, you will have atomically replaced the executable, removed any
special privileges from any links people may have hidden away, and reported (to the extent
possible without a full search of the filesystem) that somebody has been linking to
executables.

Of course, the sendmail example is a bad one as typically there is more then one valid link.
'sendmail' and 'newaliases were traditionally the same program. I know of no way to atomically
make a bunch of links to one
program so the best I can think of would be to make a bunch of temporary names for the new
execuable and then rename() them all into place sequentially in steps 2 and 3. Steps 4-6
could remain the same and would still be able to accurately report improper links while at the
same time making them useless.