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

[Charles Duffy]

On Tue, 2005-08-16 at 23:24 -0500, Ben Escoto wrote:
> >>>>> Charles Duffy <address@hidden>
> >>>>> wrote the following on Tue, 16 Aug 2005 01:07:32 -0500
> > While trying to implement the previously-discussed feature (adding a 
> > prefix to all remotely-provided paths in server mode), I've come upon 
> > what appears to be a bug in the server-mode security model.
> > 
> > Tue Aug 16 00:24:51 2005  Server sending (0): None
> > Tue Aug 16 00:24:51 2005  Client received (0): None
> > Tue Aug 16 00:24:51 2005  Making directory backup-files
> > Tue Aug 16 00:24:51 2005  Client sending (0): ConnectionRequest: 
> > os.mkdir with 1 arguments
> > Tue Aug 16 00:24:51 2005  Client sending (0): 'backup-files'
> > Tue Aug 16 00:24:51 2005  Server received (0): ConnectionRequest: 
> > os.mkdir with 1 arguments
> > Tue Aug 16 00:24:51 2005  Server received (0): 'backup-files'
> > Vetting request (ConnectionRequest: os.mkdir with 1 arguments), 
> > ['backup-files']
> > Not vetting backup-files against restricted path list
> > 
> > The last few lines are from my own instrumentation -- but nonetheless, 
> > it appears quite clearly that 'backup-files' is in this case passed as 
> > type str rather than as an RPath object, and thus that it never makes it 
> > to Security.vet_rpath(). This appears to be the case with other requests 
> > as well -- so far os.mkdir, os.listdir, os.chmod and C.make_file_dict, 
> > though I do not pretend to know of the exhaustiveness of the above list. 
> > This strikes me as a rather Bad Thing.
> 
> But C.make_file_dict, os.mkdir, etc. aren't (or at least shouldn't be)
> in the list of allowable commands.  When a security level is active,
> the first check is to make sure the command is allowed.  If it is,
> then the rpaths are checked to see if they start with the right
> prefix.

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.

> > Going back to the path-prefixing feature, I have a patch that appears to 
> > work under *very light* testing, but it's just intended as a 
> > proof-of-concept -- I have very little confidence in its correctness. 
> > Ben, I would very much appreciate any input you could provide. I would 
> > like to get this deployed to my QA department quickly, and will gladly 
> > spend time writing code as needed to do so -- but some guidance and 
> > advice would be exceedingly helpful.
> 
> Personally I don't experience managing user-run rdiff-backup sessions
> in a secure environment so I didn't reply to your earlier message.
> (Others on the list would know more about the general setup.)  But I
> didn't understand why you wanted to patch rdiff-backup instead of
> running a more standard setup, like that described on Dean Gaudet's
> page at:
> 
> http://arctic.org/~dean/rdiff-backup/unattended.html
> 
> So instead of restricting by path, it seems safer and easier to
> restrict by ssh-key and/or username.

Not workable in my situation:

- The instructions from the page in question require work to be done on
a per-server basis. I need to support tens to hundreds (and possibly
someday thousands) of servers with minimal administrative overhead.

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

- Using SSH as a transport is undesirable. I already have a VPN
providing encrypted, authenticated transport; adding a second layer of
encryption and authentication (or even just tunneling) is redundant,
unnecessarily complicating, and inefficient.