rsync - Mar 2005 - rsync as a change-detecting security tool

I suspect rsync actually *cannot* be used as a change detection
tool for security purposes, but I want some help with my reasoning.

Imagine a backup system that uses rsync to move files from client 
to a trusted server.  The backup system operates in "pull" mode,
and the backup server uses rsync to pull files from the client.
Rsync does its magic --link-dest thing, and we detect the files
that change.

My first thought was that, rather than trusting a tripwire-type 
process on the client, the log information on the server can tell
us what changed on client, away from the interference of master
system crackers on the untrusted client.

However, imagine that the client is thoroughly and deeply subverted,
including the OS itself.  We will call the pre-attack correct files
<file>-clean, and the post-attack files <file>-evil.  The client is
now running OS-evil.  When OS-evil is asked for a file by a clean
program, it will produce the clean version, but will produce the
evil version for most operations.

Rsync-clean running on the client might ask for all the client 
files to deliver to the server, but OS-evil would onlt give rsync
clean (although inactive) versions of the files to send out. 
Rsync would not report -evil versions of the files or executables
because it could not find out about them.  So any security checks
based on what rsync delivers to the server would be unreliable.

Granted, it would be a lot of work to thoroughly subvert a system
down into the OS itself.  Most real world attacks will be far less
complete, and leave lots of evidence.  Further, one can imagine
downloading specially-constructed testing programs to the client
that checksum the raw binary disk images themselves, and compare
those to checksums stored on the backup server, much like rsync
does with files but with a deeper knowledge of file system
behavior.  However, OS-evil could be instructed to lie about the
contents of the disk image itself.  

It does seem like rsync (and even tripwire on the client) cannot
be expected to detect deep attacks that affect the client OS itself.

Am I missing something here?

Keith

-- 
Keith Lofstrom          keithl@keithl.com         Voice (503)-520-1993
KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in
Silicon"
Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs

Ok. I have done some experimenting with the ""file has vanished:"
problem.

The most recent file I had exhibiting this problem was named:

"University Student's Realty Associates Power Point.ppt"

It did not exist on the receiving side of the rsysc after the run.  I
manually created the mount to the windows PC share and navigated to the
file.  I could list it with "ls" but could not "cat" it -
got an error that
"The file did not exist."

Something possessed me to remove the "'" and rename the file to:

"University Students Realty Associates Power Point.ppt"

It rsynced fine.

Just for giggles, I named it back to:

"University Student's Realty Associates Power Point.ppt"

It rsynced fine and now I can access it through the mount from a shell
terminal.  There are many files on the "source" system with
"'" in their
name, so I know the problem is not the using of the "'", but
rather with how
it is coded.

Perhaps, this is related to other posts concerning "8bit" vs.
"UTF8" vs.
"iso8859-1" vs. etc. character coding.

Take care,
Clay Goss