strip setuid/setgid bits on backup (was Re: small security-related rsync extension)

[Martin Pool]

On 16 Jul 2002, Dan Stromberg <strombrg at nis.acs.uci.edu> wrote:

> If by sillyrename, you mean busy text files are renamed to .nfs*, 

"sillyrename" is in fact the technical term for this.  I am not making
it up.  I'm pretty sure Callaghan's book calls it that, Sun people call
it that, and it is the term used in the Linux NFSv3 implementation, etc.

http://www.google.com/search?q=sillyrename

> then I think you're missing how it works yourself, I'm sorry to say.
> 
> You just unlink something on the server, and it happens, like magic.
> Maybe that happens on the client side - but that's really beside the
> point.  Rename will probably do just as well.

"it happens, like magic."  Uh-huh.

My understanding of sillyrename, from memory and a brief perusal of
the kernel source (I don't have Callaghan here), is as follows:

It is a purely client-side behaviour, to handle the fact that Unix
files may be still open when unlinked.  This relies on Unix having an
in-memory use count, in addition to the on-disk link count.  The
problem is that the NFS server may reboot while the client has the
file open, therefore losing its in-memory use count, and causing the
file data to be garbage-collected by fsck.  As a workaround, deletes
or link-replacement on the client for a file still in use are handled
by moving that file to a temporary name, so that from the
point-of-view of other clients the file has gone.  When the use count
drops to zero, the client removes the .nfs file.  If the client
crashes or the net is partitioned before the use count goes to zero,
then the .nfs file may remain indefinitely, which is why you need a
reaper run from cron.

If this is wrong please explain how.

This is, incidentally, a much better solution for replacing in-use
files than rsync's backups, because it only affects in-use files, and
they are gc'd when no longer in use.  Replacing local files and
letting the kernel handle it is even better, because it can never
leak.

> .nfs* may well suffer from the same "the backup file is still setuid"
> problem though.

Yes; if you replace in-use setuid binaries in such a way that
sillyrename orphans may be generated, then they may still be setuid,
and that may be a security problem.  I agree.

These files should only be generated by edge cases where the program
is in use when replaced, and where the client loses contact with the
server or abruptly reboots.  Presumably if you're installing a
security update to a program then you need to restart that program
fairly promptly, so the window should be small.  Of course small
window != zero, but there is no need to unnecessarily panic.

It looks like the root problem is that replacing a setuid file from an
NFS client may cause a setuid sillyrename file to remain under some
circumstances.  I haven't tested it, but I can believe that might
happen.  Is that what you're trying to say?

If this is true, then it is a problem with NFS, not with rsync.  The
failure would presumably occur in the same way if you used dpkg, rpm,
pkgadmin or cp to replace the files.

> I'm finding it hard to see why this makes the issue moot.

It is moot because you can just run rsync direct to the NFS server.
This is faster and avoids the security hole.  If you disagree, please
explain why.

> I'm also finding it hard to understand why security might be so
> unimportant to you.  I seriously wish you'd read bugtraq for a few
> months before making such a short sighted decision.

I have a pretty good understanding of Unix security, and I do consider
it important.  If you want changes to rsync you have to make a clear
case, not just wave your hands and say "like magic".

-- 
Martin