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

[Charles Duffy]

Ben Escoto wrote:

> Well I don't really understand your setup yet, but it seems any way
> you do it, the client will have to authenticate itself to the server
> somehow.  The script can just check these credentials in the same way
> your patched rdiff-backup would.
>  
It's not a matter of credentials -- I trust the client's credentials, or 
it wouldn't have been able to make the connection (I *do* have a quite 
strong authentication mechanism in place -- that's the whole VPN thing 
I've been prattling about). The issue is not allowing a "trusted" client 
in posession of a third party (this client being legitimately 
authenticated to make and retrieve its own backups) to retrieve files 
belonging to another third party. This could easily happen if one of our 
client boxen is subverted by the third party who has physical control of 
the hardware it runs on.

Consequently, the client should have the ability to connect to the 
server and make backup and restore requests -- but those requests should 
be applied within its own private namespace. Applying a host-specific 
prefix to the path it retrieves files from or stores them to seems the 
easiest way to enforce this private-namespace policy; thus, a patched 
version of rdiff-backup.

> > - 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?
> >    
>
> You need some way of setting up a pipe from one server to the other.
>  
Yes, I have one (netcat on the client, tcpsvd on the server). That's 
fine, it works -- but it rules out the (SSH-based) multi-server 
authentication mechansims which have been thus far suggested (and which 
I don't have a need for anyhow, on account of the VPN).