duplicity-talk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Duplicity-talk] security issues


From: Rob Browning
Subject: Re: [Duplicity-talk] security issues
Date: Sun, 05 Jan 2003 01:13:27 -0600
User-agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu)

Ben Escoto <address@hidden> writes:

>> One alternative might be to add a new transport, say agent:, and with
>> a target-side command, duplicity-agent, that was specifically designed
>> for use via "command=/usr/bin/duplicity-agent".  duplicity-agent would
>> be very careful to only allow the operations that duplicity requires
>> for backup and restore operations, to use chroot if appropriate, to
>> sterilize its environment, etc.
>
> Why not just ask for a chrooted ssh environment, with only access to
> ls and possibly rm?

Hmm, but then wouldn't that require a separate account for each backup
client, and a separate sshd?  It seems like without special per-user
chroot support from sshd, it could be a lot of work for the admin to
set this up for a large number of backup clients.

Even if only one chroot would be enough, that's still something that
admins would have to remember to maintain across upgrades.  Not a big
hassle, but something it'd be nice to avoid IMO.  Though some admins
might need the chroot in order to be *really* safe, I suspect that
most users, especially those using a distribution, would probably be
more likely to keep up with bugfixes without the chroot.

> (Can scp be chrooted?  I thought it worked through the ssh system,
> so chrooting one would chroot the other?)

Not sure.

> It seems unlikely that the host system's admin wouldn't trust you to
> have an account, but would trust some obscure 'duplicity-agent' tool
> which you are recommending. :)

Well I was going under the assumption that duplicity-agent would be
small and (eventually) well tested and well known.  Regardless, if
it's only running as an unprivileged user, it can't be worse than
normal ssh shell access, only better.

Maybe I wasn't clear, or I'm just misunderstanding, but I was
suggesting that in addition to having an account, the admin would
restrict the client's server-side account to running
duplicity-ssh-agent via command="".  This seemed like it would only be
safer than allowing a normal ssh shell.

(I also thought we might be able to allow the system admin to safely
 support multiple client users with only one system account, but
 that's just an "extra".)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]