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

> 
> > never seen a file created with a newline in the filename
> > (except, perhaps as a test).  The newline in filename issue
> 
> And in security exploits :-)  Given a newline-based format, one *must*
> quote or deny newlines in filenames, not assume they're rare.  (No
> obvious reason not to use URL-style %-quoting, or mime-style
> =-quoting, if you want to preserve ease of filtering...)
> 
----------
This brings up an issue that I believe can be solved in a simpler way than
with brute force C code.  I suspect some of you will cringe when you hear
this, but a taintperl log parsing program would be best for this.  rsync
could generate a verbose log file that is not human readable, designed to
be read by a perl postprocessing script.  I think this would allow greater
flexibility, and modularize the functionality to avoid some possible
security problems.  This way log parsing would not be done at the
authentication level of rsync(root) but at some lower level with read
access to the log file.  Does this sound like a reasonable solution?


						Robert Weber
						University of Colorado

On Tue, Jul 09, 2002 at 09:37:28AM -0600, Robert Weber
wrote:
> > 
> > > never seen a file created with a newline in the filename
> > > (except, perhaps as a test).  The newline in filename issue
> > 
> > And in security exploits :-)  Given a newline-based format, one *must*
> > quote or deny newlines in filenames, not assume they're rare.  (No
> > obvious reason not to use URL-style %-quoting, or mime-style
> > =-quoting, if you want to preserve ease of filtering...)
> > 
> ----------
> This brings up an issue that I believe can be solved in a simpler way than
> with brute force C code.  I suspect some of you will cringe when you hear
> this, but a taintperl log parsing program would be best for this.  rsync
> could generate a verbose log file that is not human readable, designed to
> be read by a perl postprocessing script.  I think this would allow greater
> flexibility, and modularize the functionality to avoid some possible
> security problems.  This way log parsing would not be done at the
> authentication level of rsync(root) but at some lower level with read
> access to the log file.  Does this sound like a reasonable solution?
Perl should be avoided.  Perl is proof that sysadmins don't grok
language design.

-- 
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/20020709/493cd266/attachment.bin