Re: [Duplicity-talk] adding stronger server-side protections for ssh backups.

[Rob Browning]

Ben Escoto <address@hidden> writes:

> I like this plan because it is relatively simple and kills three
> birds with one stone.  I have not thought about the security of it
> yet though, so I may be missing something.

Definitely possible.

> The dssh URL syntax seems a bit non-standard and confusing to me,
> but I can't think of a better way offhand.  Maybe I will look at the
> rfcs again.

Yeah.  I just picked it at random -- I'm not particularly attached to
it.

> So do you feel like writing this 'duplicity-ssh-agent' command and the
> associated documentation?  That will be 90+% of the work probably.

Sure I'll try to give it a shot.  I may be a little slow, so if anyone
else wants to work on it, that'd be fine too.

> Maybe it would be best to write it in shell, in case python or other
> languages aren't available on the server.

Shell might work, but I'm a little hesitant just because it's
typically much harder to create a safe shell script.  Would perl be
acceptable?  Perl seems pretty ubiquitous these days and seems to make
it fairly easy to protect against some of the most common problems.
Just turning on taint checking and making sure to always pass a list
to system/exec/etc rather than a string can help quite a bit.

> Once that is done it should be pretty trivial to add support for
> this new "dssh" protocol since, as you said, a backend only has to
> implement put, get, list, and delete.

One other option that might have broader usefulness would be to try
and work with the ssh people (or the rsync people) to come up with
some way to reliably restrict scp or rsync to a subdirectory.  However
this wouldn't help wrt the ssh commands that duplicity needs.

As most of the functionality duplicity needs is pretty general: put,
get, list, and delete, I also wonder if there's some way we could do
something of more general use -- perhaps create a "restricted command
processor" or similar that could be used by duplicity and others.
Basically a really restricted shell, but not as restricted as say
rssh.  Now that I think about it, an enhanced sftpsh (a command
currently provided by rssh) might do the trick, one that supported
args like --disable-put --root=foo, etc. and could use those args to
affect the sftp-server invocation.  Something similar could be done
for rsync --server.

Hmm...

-- 
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