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

[Dan Stromberg]

On Tue, Jul 09, 2002 at 02:36:22PM -0700, jw schultz wrote:
> 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.

This might work.  Will it still keep all my rwx bits intact?

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

Have you ever read bugtraq on a regular basis?  They're coming out of
the woodwork.

-- 
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/20020711/37996aa6/attachment.bin