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

[jw schultz]

On Tue, Jul 09, 2002 at 11:03:25AM -0700, Dan Stromberg wrote:
> On Mon, Jul 08, 2002 at 02:04:57PM -0700, jw schultz wrote:
> > 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.
> 
> We're not modifying the content of files; we're eliminating security
> holes.  Surely folks see the sense of this?

Then don't use the --perms option.

> 
> Important things shouldn't be hard to do (you shouldn't have to parse a
> log and write a shell script to do what should be default behavior),
> just as dumb things shouldn't be easy to do (EG, clicking on attachments
> in lookout).
> 
> > 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.
> 
> If you had ever seen something like the huge software library we give to
> our clients, you wouldn't say this.  We simply must have set[ug]id, but
> only for secure binaries.  Having an insecure setuid root ~ file is a
> vastly larger problem than not being able to run some ~ file without
> minimal sysadmin intervention first.

I don't get what you are doing.  Where did these insecure
suid root files come from in the first place?

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

		Remember Cernan and Schmitt