[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [rdiff-backup-users] SECURITY: Not all file ops accessed via vetted
From: |
Ben Escoto |
Subject: |
Re: [rdiff-backup-users] SECURITY: Not all file ops accessed via vetted RPath objects? Also a path prefixing patch |
Date: |
Wed, 17 Aug 2005 01:33:26 -0500 |
>>>>> Charles Duffy <address@hidden>
>>>>> wrote the following on Tue, 16 Aug 2005 23:58:22 -0500
>
> 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.
Well unless you use an option like --restrict*, security is pretty
limited: it just tries to prevent a situation where you run
"rdiff-backup source host::dest" and the remote rdiff-backup on host
is actually hacked and tries to read/delete inappropriate files on the
local side. On the destination side everything is fair game.
Anyway, how are you running rdiff-backup? I'll check out the
mkdir()'s and similar you are finding.
> - 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.
What's the problem with having thousands of users? It seems that
would be the safest way. Otherwise, why not write a script that
checks the arguments to rdiff-backup, instead of patching
rdiff-backup?
--
Ben Escoto
pgpuLPFkn6RV3.pgp
Description: PGP signature
- [rdiff-backup-users] SECURITY: Not all file ops accessed via vetted RPath objects? Also a path prefixing patch, Charles Duffy, 2005/08/16
- [rdiff-backup-users] Update to that path prefixing patch, Charles Duffy, 2005/08/16
- Re: [rdiff-backup-users] SECURITY: Not all file ops accessed via vetted RPath objects? Also a path prefixing patch, Ben Escoto, 2005/08/17
- Re: [rdiff-backup-users] SECURITY: Not all file ops accessed via vetted RPath objects? Also a path prefixing patch, Charles Duffy, 2005/08/17
- Re: [rdiff-backup-users] SECURITY: Not all file ops accessed via vetted RPath objects? Also a path prefixing patch, Ben Escoto, 2005/08/18
- Re: [rdiff-backup-users] SECURITY: Not all file ops accessed via vetted RPath objects? Also a path prefixing patch, Charles Duffy, 2005/08/18
- Re: [rdiff-backup-users] SECURITY: Not all file ops accessed via vetted RPath objects? Also a path prefixing patch, Ben Escoto, 2005/08/20
- Re: [rdiff-backup-users] SECURITY: Not all file ops accessed via vetted RPath objects? Also a path prefixing patch, Charles Duffy, 2005/08/20
- Re: [rdiff-backup-users] SECURITY: Not all file ops accessed via vetted RPath objects? Also a path prefixing patch, dean gaudet, 2005/08/17
- Re: [rdiff-backup-users] SECURITY: Not all file ops accessed via vetted RPath objects? Also a path prefixing patch, Charles Duffy, 2005/08/17