Joshua Marshall wrote:
> It wont stop an attacker from doing that, no. But as pointed out by Daniel
> Poelzleithner he will already have access to the data on the machines. That
> includes access to the /etc/shadow file which he can go away and find out all
> your passwords using a cracking tool, then get in via ssh anyway.
I'm not familiar with the endurance of the crypt used to encode the
passwords in /etc/shadow, but we always use very long root passwords,
consisting of alfanumeric & other characters.
> I took a quick look at the website you originally posted, it seemed to suggest
> that the rsyncd server was being spawned via the shell over ssh but it didn't
> really say that the data going to/from the rsync server would then be
> encrypted.
I believe your right about this :(
> An option that you do have is to have the rsyncd server running, allowing
> connections only to localhost. Have a pre-backup script start up an ssh
> tunnel to the server and port forward the rsyncd port on the machine being
> backed up to the backup machine, then get the backup to use the encrypted
> link. I'm not sure on the specifics but it's a start.
Very interesting approach! I will definately explore this possibility.
Thanks for the idea.
Strange however, that these security concerns are discussed so little in
the backuppc documentation?

Craig Barratt wrote:
> Not sure. I've tried to replicate this bug without success.
>
> I've written test programs that have created thousands of
> files of various sizes, done full and incremental backups,
> changed random subsets of data in the files, and repeated
> many times without any errors. I also upgraded to perl 5.8.3
> and still no problems. I've tried rsync 2.6.0 and 2.5.6.
I looked at the checksum cache code. Whats with the condition a file
with none checksum cache do have the magic ?
I dislikes the idea of altering pool files to add the checksum in the body.
I suggest another solution:
1. Something like $filename.metas which can store addition informations
like checksums,...
2. Implement a real container format, it can be really simple, but
should provide flexibility for future developments.
3. A database driven checksum database. gdb would does the job, but
something like sqlite would allow feature usage. The nightly job would
simple remove the entry when the file is unlinked.
regards
Daniel

On Sat, 17 Apr 2004 23:58, Jan-Frederik wrote:
> But this doesn't really solves the problem, or does it? What is to stop
> an attacker from login in as a non-root user on the client machine,
> executing sudo rsync, and overwriting /etc/shadow with a version in
> which he has altered the pasword crypt for the root user?
It wont stop an attacker from doing that, no. But as pointed out by Daniel
Poelzleithner he will already have access to the data on the machines. That
includes access to the /etc/shadow file which he can go away and find out all
your passwords using a cracking tool, then get in via ssh anyway.
> > I personally now use the rsyncd for machines that are on their own
> > private network (ie DMZ) as it is easier to back up both unix and win
> > machines this way. If you are using public networks you are best to use
> > ssh with a non-root user and sudo.
>
> So rsyncd+ssh for use public networks, combined with backuppc would not
> be possible in your opinion?
I took a quick look at the website you originally posted, it seemed to suggest
that the rsyncd server was being spawned via the shell over ssh but it didn't
really say that the data going to/from the rsync server would then be
encrypted. If that isn't the case then you are just as well off having an
rsyncd server with the plaintext passwords.
An option that you do have is to have the rsyncd server running, allowing
connections only to localhost. Have a pre-backup script start up an ssh
tunnel to the server and port forward the rsyncd port on the machine being
backed up to the backup machine, then get the backup to use the encrypted
link. I'm not sure on the specifics but it's a start.
Another option would be to have a vpn such as openvpn / vtund / tinc whatever
(entirely different thread) between the backup machine and all others to
encrypt the data. By using a good vpn it should be as secure (maybe more)
than using ssh.
Regards,
Josh.