bugrdiff-backup - Bugs: bug #16897, Security Violation on first...

 
 

bug #16897: Security Violation on first increment while using restrict-update-only

Submitter:  None
Submitted:  Tue 20 Jun 2006 09:37:53 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Need Info
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Sat 12 Jan 2008 04:19:35 AM UTC, comment #5: 

more thoughts on this... if i were to try to do a push backup system where all the clients shared a common private key i think what i'd do on the server is have the .ssh/authorized_keys command="foo" invoke a script of my own (you'd probably need a remote-schema change too).

the script on the server would validate the SSH_CLIENT env var contains a client which is supposed to be backed up, and then mkdir /mnt/backups/$IP as necessary and finally exec rdiff-backup --server --restrict-update-only /mnt/backups/$IP.

this way the clients can't trash each other easily (assuming rdiff-backup --restrict-* are actually secure :)

but hey... go ahead and add os.mkdir i guess.

-dean

dean gaudet <dgaudet>
Group administrator
Thu 10 Jan 2008 06:47:00 AM UTC, comment #4: 

i'm of very mixed opinion.

if you use a single key restricted to:

rdiff-backup --server --restrict-update-only /mnt/backups/

then any of the boxes which have that key can do whatever they want to any of /mnt/backups/subdirs... i.e. they could erase some other server's backup.

personally i think this is a configuration not worth supporting -- it's not secure.

the only configuration which works is to give a dedicated key to each of the servers pushing a backup.

-dean

dean gaudet <dgaudet>
Group administrator
Sun 06 Jan 2008 02:59:24 AM UTC, comment #3: 

Sounds like an argument for moving os.mkdir into the list allowed by update-only as well. It's a 1-line patch.

Dean, thoughts?

Andrew

Andrew Ferguson <owsla>
Group administrator
Sun 06 Jan 2008 02:33:10 AM UTC, comment #2: 

I can verify that this is still a problem in 1.1.14.  If you use the --restrict-update-only option the first backup will fail.  So if you have a server that's set to receive rdiff-backup pushes from clients you currently have to set the server to --restrict for the first backup and then change it to --restrict-update-only for subsequent backups.  The ideal behavior would be to treat a first backup as an "update" and allow it to run as it does under --restrict, that is still constrained to the specified directory.

In other words if you have rdiff restricted via ssh key to running as:

rdiff-backup --server --restrict-update-only /mnt/backups/

And the request is to backup to /mnt/backups/newserver then if the directory /mnt/backups/newserver exists then process as happens now.  If it doesn't exist then allow the creation of the first backup so long as the directory is still within the one specified by the restrict statement.

Anonymous
Sat 19 May 2007 06:57:44 PM UTC, comment #1: 

there've been several fixes in this area... please re-open if the problem still exists in latest cvs.

dean gaudet <dgaudet>
Group administrator
Tue 20 Jun 2006 09:37:53 PM UTC, original submission:  

I created some remote backups and then set up a "secure" enviroment with the help of --restrict and --restrict-update-only. In the directories where the backup was created and then incremented (before I setup this flags) everything works as it should, but (!!) in the directories where there hasn't been an increment (till now) I now (with the restrictions set up) get the following error:

Traceback (most recent call last):
  File "/usr/bin/rdiff-backup", line 23, in ?
    rdiff_backup.Main.error_check_Main(sys.argv[1:])
  File "/usr/lib/python2.3/site-packages/rdiff_backup/Main.py", line 295, in error_check_Main
    try: Main(arglist)
  File "/usr/lib/python2.3/site-packages/rdiff_backup/Main.py", line 315, in Main
    take_action(rps)
  File "/usr/lib/python2.3/site-packages/rdiff_backup/Main.py", line 271, in take_action
    elif action == "backup": Backup(rps[0], rps[1])
  File "/usr/lib/python2.3/site-packages/rdiff_backup/Main.py", line 328, in Backup
    backup_final_init(rpout)
  File "/usr/lib/python2.3/site-packages/rdiff_backup/Main.py", line 432, in backup_final_init
    if not inc_base.lstat(): inc_base.mkdir()
  File "/usr/lib/python2.3/site-packages/rdiff_backup/rpath.py", line 863, in mkdir
    self.conn.os.mkdir(self.path)
  File "/usr/lib/python2.3/site-packages/rdiff_backup/connection.py", line 448, in _call_
    return apply(self.connection.reval, (self.name,) + args)
  File "/usr/lib/python2.3/site-packages/rdiff_backup/connection.py", line 370, in reval
    if isinstance(result, Exception): raise result
rdiff_backup.Security.Violation:
Warning Security Violation!
Bad request for function: os.mkdir
with arguments: ['/target/backup/dir/rdiff-backup-data/increments']

The solution would be to allow os.mkdir to create directories if they are in the rdiff-backup-data subdirectory inside of the restricted path! Or to create ALL subdirectories inside rdiff-backup-data that could be needed at some point in the future when the program is executed at the first backup!

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by owsla (Posted a comment)
  • -email is unavailable- added by dgaudet (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-05-19 dgaudet StatusNone Need Info
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code