Re: [rdiff-backup-users] SECURITY: Not all file ops accessed via vetted RPath objects? Also a path prefixing patch

[Charles Duffy]

On Wed, 2005-08-17 at 01:33 -0500, Ben Escoto wrote:
> >>>>> Charles Duffy <address@hidden>
> >>>>> wrote the following on Tue, 16 Aug 2005 23:58:22 -0500
> > 
> > If they aren't in the list of allowable commands, why am I seeing the
> > client sending such requests and the server processing them? I don't
> > thoroughly understand at what times and under what circumstances
> > security levels are active, but (without better understanding what's
> > going on) the behaviour in question seems a touch suspect.
> 
> Well unless you use an option like --restrict*, security is pretty
> limited:  it just tries to prevent a situation where you run
> "rdiff-backup source host::dest" and the remote rdiff-backup on host
> is actually hacked and tries to read/delete inappropriate files on the
> local side.  On the destination side everything is fair game.

Hmm. See, my concern is protecting inappropriate files on host from
being accessed. Perhaps I'll want to use a different security layer in
addition to application-based measures.

> Anyway, how are you running rdiff-backup?  I'll check out the
> mkdir()'s and similar you are finding.

On the server:
  rdiff-backup --server --restrict "$DATAPATH" --force-path-prefix "$DATAPATH"
(where DATAPATH is based on, among other things, the connecting system's
hostname; this is all behind tcpsvd, http://smarden.org/ipsvd/)

On the client:
  rdiff-backup --remote-schema 'netcat %s 10873' /RecareEE/data/backed-up 
10.1.128.1::/backup

> > - I don't trust the servers to accurately identify themselves (ie. to
> > choose locations under the backup account on which to store data). These
> > servers are in the posession of various clients, and store data
> > proprietary to said clients. If a client could subvert the backup system
> > to download another client's data (as is possible when all servers share
> > a single backup account without per-system pathname limitations), it
> > would be a Very Bad Thing. Because of the number of servers in question,
> > creating multiple backup accounts (to isolate the servers from each
> > other) is likewise unworkable.
> 
> What's the problem with having thousands of users?  It seems that
> would be the safest way.  Otherwise, why not write a script that
> checks the arguments to rdiff-backup, instead of patching
> rdiff-backup?

- Checking the arguments to rdiff-backup:
  Would you do this checking on the server or the client? Remember, I
don't trust the client (which may have been subverted to try to retrieve
another machine's backups), so it needs to be done on the server. Does
the server have a nonspoofable way to check the client's command-line
arguments without patching?

- Passing arguments specific to the client:
  One option to workaround this is, on the server, to detect the host
the client connected from and generate a custom restrict path, such as
"--restrict /path/to/backups/for/CLIENTNAME". This means that each
client must be run as something along the lines of
"rdiff-backup /path/to/backed-up-data
server::/path/to/backups/for/MYHOSTNAME". This means that
"/path/to/backups/for" must be agreed upon between client and server,
which is ugly: Why should the client need to know anything about the
server's filesystem structure? And since the host knows who it thinks
the client is, why should the client need to pass in its name as well?

- Extra overhead/complexity from SSH
  I brought this concern up earlier, and it hasn't been answered. Why
bother with host keys, RSA authentication, and (unless disabled)
encryption overhead when there's already a VPN in place providing a
guarantee that the hosts are who they say they are?