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

[jw schultz]

On Mon, Jul 08, 2002 at 05:56:57PM +1000, Martin Pool wrote:
> Any thoughts on whether this should go in?  I can see arguments either
> way.  It seems like we ought to think about whether it would be better
> to do it as part of a generalized --chmod or --chmod-backup facility.
> 
> 
> 
> On 21 Jun 2002, Dan Stromberg <strombrg at nis.acs.uci.edu> wrote:
> > Included below is a shar archive containing two patches that together:
> > 
> > 1) make backup files get their setuid and setgid bits stripped by
> > default
> > 
> > 2) add a "-s" option that allows backup files to continue to have
> > these privileges
> > 
> > This means that if you update a collection of binaries with rsync, and
> > one or more of them has a local-root security problem, the backup
> > file(s) created when you fix the problem in your source archive won't
> > remain exploitable.

Having considered the various sides elsewhere in this thread
i would say this patch is a definite no-no.

The default behavior should not modify files.  The general
purpose is to have the copies be the same as the original.
A general --chmod or --pmask option might be acceptable for
modifying the permissions flags but would need to be applied
in generator as well as reciever.

For almost any case like this the way to deal with it is in
the mount options.  For -s to be active and ownership
preserved root has to be doing the transfer anyway.  Try
mounting the filesystem -o noexec,nodev  That way the backup
will have all the same permissions bits but there need be no
worry about users abusing it if given access.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt