Authorization: Security Issues: Revisions vs. Paths

[Daniel Kastenholz <da...@in.tum.de>]

Hi,

I have a question regarding the fundamental security concept behind 
authorizations in Subversion.

The situation is that I have now a repository that grants r/w access to 
all team members, but due to a team enlargement, I need to hide certain 
documents from new members. I'm now trying to find out how to accomplish 
this. My first idea was this:

Assume I have a repository structure like this in Revision 100:

/
    /folder
        /secret-A
        /secret-B

Now I figure out that some better not access A and others shouldn't 
access B. So in revision 150 I change the structure as follows, say, by 
moving the files:

/
    /folder-1
        /secrets
           /group-1
              /secret-A
           /group-2
              /secret-B

Then I define the authorization table as follows (which seems the only 
way to ensure that everybody can access their resources):

[/]
*=r
[/folder-1/secrets/group1]
*=
@group1 = rw
[/folder-2/secrets/group2]
*=
@group2 = rw

Question 1:

what would prevent anyone from going back to revision 100 and reading 
the contents even without permissions!?

Question 2:

correct me if I'm wrong, but Subversion's entire security system seems 
to be blacklist-based to me, i.e. I first have to grant access to 
everybody on everythig and then restrict access for those resources that 
I don't want certain people to see. But isn't that exactly the approach 
that should be avoided in every security-related environment (firewalls, 
filesystems, etc.)?! Wouldn't it need a whitelist-oriented approach to 
make the authorization system waterproof?

Actually, the root cause of the problem seems to have to do with how 
Subversion treats the parent folders in authorization declarations. 
Linux, for instance, allow users to jump into a deep subfolder even if 
they do NOT have read permissions on the parent folders. Subversion 
seems to lack this functionality.

Take

[/folder-1/secrets/group1]
@group1=rw

For this declaration to work, it appears that I also need to grant 
access to "/folder-1" and "/folder-1/secrets" before group1 can actually 
access the resource. But that's insane, as it would also grant access to 
everything EXCEPT the resource to group-1 if nothing else is stated. And 
now assume that somebody forgot to explicitly protect a critical 
resource, or probably made a typo or renamed that critical resource 
without updating the authorization file. Result: security hole.

Or am I just panicking?!


Daniel

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Authorization: Security Issues: Revisions vs. Paths

[Daniel Kastenholz <da...@in.tum.de>]

PPS:

Just found a solution to question #1 myself (#2 is still open).

It should be possible to
- dump the old repository
- create a new repository with the more complex base structure and 
permissions
- load the contents of the old one into a secure SUBfolder ("/secure") 
that is only accessible by the admin
- move the secret files from "/secure" to their new locations

That should remove all evidence of the secret files on root (i.e. 
public) level, but still preserve their history for those that need it. 
(-> will the history be browseable from the new location?)


Daniel Kastenholz schrieb:
> Hi,
>
> I have a question regarding the fundamental security concept behind 
> authorizations in Subversion.
>
> The situation is that I have now a repository that grants r/w access 
> to all team members, but due to a team enlargement, I need to hide 
> certain documents from new members. I'm now trying to find out how to 
> accomplish this. My first idea was this:
>
> Assume I have a repository structure like this in Revision 100:
>
> /
>    /folder
>        /secret-A
>        /secret-B
>
> Now I figure out that some better not access A and others shouldn't 
> access B. So in revision 150 I change the structure as follows, say, 
> by moving the files:
>
> /
>    /folder-1
>        /secrets
>           /group-1
>              /secret-A
>           /group-2
>              /secret-B
>
> Then I define the authorization table as follows (which seems the only 
> way to ensure that everybody can access their resources):
>
> [/]
> *=r
> [/folder-1/secrets/group1]
> *=
> @group1 = rw
> [/folder-2/secrets/group2]
> *=
> @group2 = rw
>
> Question 1:
>
> what would prevent anyone from going back to revision 100 and reading 
> the contents even without permissions!?
>
> Question 2:
>
> correct me if I'm wrong, but Subversion's entire security system seems 
> to be blacklist-based to me, i.e. I first have to grant access to 
> everybody on everythig and then restrict access for those resources 
> that I don't want certain people to see. But isn't that exactly the 
> approach that should be avoided in every security-related environment 
> (firewalls, filesystems, etc.)?! Wouldn't it need a whitelist-oriented 
> approach to make the authorization system waterproof?
>
> Actually, the root cause of the problem seems to have to do with how 
> Subversion treats the parent folders in authorization declarations. 
> Linux, for instance, allow users to jump into a deep subfolder even if 
> they do NOT have read permissions on the parent folders. Subversion 
> seems to lack this functionality.
>
> Take
>
> [/folder-1/secrets/group1]
> @group1=rw
>
> For this declaration to work, it appears that I also need to grant 
> access to "/folder-1" and "/folder-1/secrets" before group1 can 
> actually access the resource. But that's insane, as it would also 
> grant access to everything EXCEPT the resource to group-1 if nothing 
> else is stated. And now assume that somebody forgot to explicitly 
> protect a critical resource, or probably made a typo or renamed that 
> critical resource without updating the authorization file. Result: 
> security hole.
>
> Or am I just panicking?!
>
>
> Daniel
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Authorization: Security Issues: Revisions vs. Paths

[Daniel Kastenholz <ma...@danielkastenholz.de>]

I just tested that and it seems to be wrong. Linux doesn't do that. 
Forgive me.
But I guess that's how it should be in Subversion ...


Daniel Kastenholz schrieb:
> Linux, for instance, allow users to jump into a deep subfolder even if 
> they do NOT have read permissions on the parent folders.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org