>>>>> Charles Duffy <[EMAIL PROTECTED]> >>>>> 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
pgpWYLEwWYGH7.pgp
Description: PGP signature
_______________________________________________ rdiff-backup-users mailing list at [email protected] http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
