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

[Martin Pool]

On 11 Jul 2002, Dan Stromberg <strombrg at nis.acs.uci.edu> wrote:

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

Another question would be, why do you want to keep them around at all?
Presumably so that people can undo the changes if something goes
wrong?

For your situation, it might work better to dump them all into a mode
700 backup directory.

It seems like the overarching problem is different focusses: Dan wants
rsync to be a software-distribution mechanism (which is certainly a
good use for it), which which case stripping setuid bits is obviously
quite desirable.  But for a bit-perfect backup tool, it's probably
wrong.

I have been thinking about what general strategies software tools use
to address this problem of focus.  They seem to be

1- Add a pile of built-in options (--strip-setuid) -- rsync's strategy
   to date.

2- Build a common layer, and then variations on the program to suit
   different purposes.  I think rdiff-backup is kind of like this.
   It has the advantage that end users who "just want to do backups"
   or software distribution or mirroring don't need to deal with 

3- Make the program call out to various scripts that can control its
   behavior -- the CVS server is like this, for example, with loginfo
   scripts and so on.

4- Make the program's interfaces and performance characteristics be
   such that it can easily be controlled by a scripting language.
   Subversion is trying to be like this.  The --log-format proposal
   for rsync goes in this direction, though needing a new socket for
   each invocation rather cripples it.

5- Make the whole program intimately intermingled with a scripting
   language, like emacs or (perhaps) Mozilla.

-- 
Martin