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

[Dan Stromberg]

On Fri, Jul 19, 2002 at 01:00:22PM +1000, Martin Pool wrote:
> 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

That's fine.

> > 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.

That's a little insulting.

> 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.

1) This is an interesting, but quite irrelevant implementation detail
with respect to the subject matter at hand.  If you like, I can now tell
you something you didn't know.  Maybe I'll score some points.  I'll make
sure it's irrelevant, too.

2) sillyrename isn't as effective as what rsync's backup files could be,
if rsync's backup files aren't left privileged.

> > .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?

The root problem is that rsync's backup files are privileged, and
shouldn't be.  An average rsync newbie isn't going to read the doc and
decide whether they need to construct a pipeline to make their security
reasonable; they're just going to run it and assume it does something
reasonable in the first place.  How many pro sysadmins do you know who
have time to read doc for something that seems to be working as it
should already?

> 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.

It's currently a problem in both.  Neither of us has the power to fix it
in nfs, but you have the power to fix it in rsync.  (Yes, we could do it
in linux and *bsd nfs, but that's far from the entire unix world).

I just verified that with a Redhat 7.3 NFS client and a Solaris 7 NFS
server, I get a setuid .nfs* file.

> > 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.

Because the .nfs files can be setuid anyway.

> > 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".

When it's an implementation detail, "like magic" is more appropriate.  I
can read kernel source, but now wasn't the time for it.

-- 
Dan Stromberg                                               UCI/NACS/DCS
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://lists.samba.org/archive/rsync/attachments/20020719/2134f59e/attachment.bin