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

[Ben Escoto]

On Sun, Jan 05, 2003 at 10:58:02AM -0600, Rob Browning wrote:
> 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.

I don't program in shell, so I don't know how hard it is to make a
safe shell script (but note that here it seems an attacker can't mess
with the environment).  Also, I was under the impression that there
are various incompatible versions of Perl, but that might be quite
wrong.  Anyway, since you're writing it you get to choose the
language.  If someone else has a burning need for it in bash, they can
write it themselves.  You still would have done most of the work
deciding on the general design and syntax, and writing the
documentation.

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

Duplicity by design demands as little as possible of its backends:
get, put, list, and delete (hmm, maybe list is unnecessary? oh well).
Almost any other protocol will need more functionality, which could
make writing the server side tool orders of magnitude more
complicated.  For instance, this problem comes up with rdiff-backup,
which tries to deal with it through options such as
--restrict-update-only.  The code dealing with --restrict-update-only
is closely integrated with the rest of the rdiff-backup code, and I
don't see how any general tool could help.

So anyway it seems to me that the very simple put/get/list/delete
duplicity wrapper has a definite niche and would be useful enough to
justify the programming involved (probably < 100 lines of perl?).

If you wanted to write a more general tool, or add features to the ssh
package, that might be useful, and maybe more backends could be added
to duplicity to support them.  But the simple tool you proposed
earlier would still be useful, since it can be used by anyone with ssh
access, and doesn't require any help from the sysadmin.


-- 
Ben Escoto

pgpZfME8AoeE7.pgp
Description: PGP signature