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

[Ben Escoto]

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

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


-- 
Ben Escoto

pgpsAlt3aRSCp.pgp
Description: PGP signature