[tahoe-dev] Tahoe performance

Jack Lloyd lloyd at randombit.net
Sat Feb 21 02:03:17 UTC 2009


On Thu, Feb 19, 2009 at 02:19:42PM -0800, Brian Warner wrote:

> the same weak checksums), and put A1 on the destination machine and A2
> on the source, then 'rsync ./A2 remote:A1' would fail to properly
> replace A1 with A2. But they're both your own files anyways.

Not necessarily: I can think of many scenarios where it might be
advantageous to ensure that rsync (or more generally, the system
backup) would skip backing up a new version of a file. Such situations
can occur anytime the creator of the file has interests that do not
align with the person performing the backup operation.

For instance, say I wish to hide a logic bomb on a corporate server,
that six months after I left the company would activate and perform
some unfriendly action. However I don't want to leave evidence behind,
and the machine in question is backed up nightly to an incorruptible
offsite system. If I simply uploaded the malicious executable, after
it triggered one could go back and find said malicious code in the
backups, providing forensic evidence that could be used against me. So
instead I could prepare two files, the logic bomb executable plus an
innocouous file which rsync would consider to be identical. Since most
binary formats (eg ELF binary files, Office documents) are quite
flexible, I could perhaps even create my dummy file to be something
meaningful. Then I place the innocouous version where it will be
backed up, after which I replace it with the malicious version. Then
numerous backup operations would occur, and (assuming the malicious
version deleted or replaced itself after triggering) leave no evidence
behind, without having to corrupt the backup server or process itself.

-Jack



More information about the tahoe-dev mailing list