Re: [Duplicity-talk] how might you keep remote backups safe given a hacked machine?

[Rob Browning]

Ben Escoto <address@hidden> writes:

> Yes, this is a good point and well worth considering.  The basic
> problem is that there seems to be two different access modes that
> might be necessary.  Basic backing up only requires write access,
> while options like --cleanup and --remove-older-than delete files.
>
> Well there really might be two problems: 1) enabling write only
> access, 2) restricting yourself to write-only access most of the time
> while still giving yourself full access sometimes.

I'm wondering if in some cases you might want to have a setup where
the clients don't ever have full access.  i.e. if you want full
access, you log in to the backup server and run the commands as
someone in the right group.  That's what I'd be most likely to want to
do here.  I don't need to be able to --cleanup from my client
machines, and I'd rather not even allow the possibility.

> About problem 1), if in write-only mode you didn't allow yourself any
> file modification abilities, then you could get something similar to
> write-only mode by hard linking all the new files with a different
> user.  You could always just copy them over with a different user, but
> this would use twice the space.  I think if you hade root on the
> remote machine, it should be safe to chown the existing files, and
> then hard link them.  The duplicity user could delete the files, which
> wouldn't do anything (since they would still be hard linked), but
> could not modify the existing files.

Hmm.  Seems like you'd have to be careful here that you didn't leave a
window of danger open, though perhaps that would just be a "known
risk"...

> If you wanted a pull mode, why not just back up locally and have the
> server get the files?  There may currently be some sanity checking
> preventing this, but otherwise you don't need any files in the target
> directory for normal backup operations, assuming you use the
> --archive-dir option.

Because it seems like a compromised client, could just delete all the
files in the local backup and then on the next sync, the server's
backups would be destroyed.  With something like --append-only, that
can't happen.  Or am I misunderstanding what you're suggesting?

> About problem 2), maybe there is some clever way of doing this with a
> normal ssh account.  Perhaps you could alter your shell to give you a
> chroot account, unable to modify any files, but with access to a
> special command, which, when supplied with a password, would restore
> your normal abilities.

That might work, but it seems like you'd have to somehow have root
access to be able to perform the chroot, and at least to me, this
approach seems like it might be complicated enough that the command=""
wrapper would be preferable.  Of course, this assertion should be
taken with a fairly large grain of salt, being based solely on my
naive initial examination of the issues.

Thanks

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4