strip setuid/setgid bits on backup (was Re: small security-related rsync extension)
strombrg at nis.acs.uci.edu
Thu Jul 11 18:58:21 EST 2002
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
Dan Stromberg UCI/NACS/DCS
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 232 bytes
Desc: not available
Url : http://lists.samba.org/archive/rsync/attachments/20020711/37996aa6/attachment.bin
More information about the rsync