secure remote backups

Ben Escoto bescoto@stanford.edu
Mon, 17 Dec 2001 18:49:06 -0800


--==_Exmh_-1637332024P
Content-Type: text/plain; charset=us-ascii

>>>>> "MW" == mike wolman <mike@nux.co.uk>
>>>>> wrote the following on Tue, 18 Dec 2001 00:41:20 +0000 (GMT)

  MW> When i run rdiff-backup with the following remote schema:
  MW> --remote-schema "ssh -C %s '/home/backupuser/backup.sh'" \

  MW> I am prompted for a password, i do not plan to run this via a
  MW> cron job so will actually be there to enter the password - i am
  MW> planning on using ssh keys (with passphrase). Would this then
  MW> not be the same risk as allowing user mike ssh access?

Yes, I think the risk is the same; I was assuming you had set it up in
a cron job or something.

  MW> I should run Aide or tripwire check before each backup to ensure
  MW> the machines being backuped have not been comprimised.  My main
  MW> concern is 4. and the main backup server being comprimised, i
  MW> presume chrooting rdiff-backup to each machines backup directory
  MW> wont be possible.

chrooting would be a good idea and more secure, but the problem is
that rdiff-backup keeps running the rdiff executable.  After the
chroot, rdiff would no longer be available.  One possible solution is
to use librsync, and to create python bindings for those, so that
everything is is loaded before the chroot.  However, I would have to
learn about C and C/Python bindings, and rdiff-backup would have to be
compiled and the libraries would be platform-specific, so it would
become more complicated and harder to install.

    I suppose maybe you could just hardlink the rdiff executable into
some subdirectory of the new root, so it would still be accessible.
But this solution is a bit of a hack and doesn't seem very
maintainable.

    About (4), to be honest, currently rdiff-backup doesn't do some
checking that it could/should.  For instance, a user after hacking the
server could enter in some pathnames like "../../../etc/passwd" or
whatever, causing those files to be rewritten on the server.  So
sorry, but what you are worried about could happen.  I will get around
to examining all these issues.

    I forgot the original conversation, but if you are just trying to
back up stuff in /home, and none of the files are owned by root,
perhaps you could run a different rdiff-backup process for each user,
where at all times, both sides are owned by the user whose files are
being backed up.  This I think would be theoretically secure, no
matter what oversights are in rdiff-backup.


--
Ben Escoto

--==_Exmh_-1637332024P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Exmh version 2.5 01/15/2001

iD8DBQE8Hq6C+owuOvknOnURAu/AAJ4zSPqKK5aywC2N0l1f2KL4xhkYZwCffL7L
54rNc9etnXxGNydAetaxhyY=
=RUMp
-----END PGP SIGNATURE-----

--==_Exmh_-1637332024P--