[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: RFC: Subversion security model in need of update

From: Branko Cibej <brane_at_xbc.nu>
Date: Thu, 12 Mar 2009 20:37:55 +0100

C. Michael Pilato wrote:
> Branko Čibej wrote:
>
>> I've been thinking about Mike's example where you commit to two sibling
>> directories whose parent you're not allowed to read. It's
>> "straight-forward" to allow the editor to open the node but disallow any
>> operations except child lookup on it; but that means the access check
>> can no longer be done at node-open time -- or rather, it can if you
>> assume the filesystem like model where you specify desired access in the
>> open call, but it has to be enforced later on, too. Doing this on the
>> server level (mod_dav_svn or svnserve) is, IMO, likely to cause more
>> problems than it's worth. So that implies moving the access control to
>> the FS layer. Something I've been advocating all along. :)
>>
>> -- Brane
>>
>
> Most of the time, I don't think we really need a directory traversal bit,
> per se. We need only to understand that if somebody has read access to
> /foo/bar/baz, Subversion needn't pretend that /foo and /foo/bar don't exist.
> That doesn't require a single new authz access level -- "r" and "rw" still
> do what you want. It just requires a new application of those existing rules.
>

Yeah, what I said -- we can just assume it's implicitly there. But you
still have to do the access checks on the actual read/write ops, doing
'em on node-open isn't enough. (Maybe I'm missing something and it's
already done that way. Still, it would be nicer if that were done in the
FS layer.)

> The one catch is that if we continue to leak siblings as we do today, there
> is some additional security in the model today that we will lose if we go
> forward as I'd like to. A dictionary attack can reveal only the top-most
> unreadable item. So if I don't have access to /private, I might be able to
> learn that /private exists with a dictionary attack and a bunch of mkdirs(),
> but I can't learn that, say, /private/competitor exists. Today if I have
> access to /foo/bar/baz, I can't even perform such an attack on /foo/* (for
> lack of access to /foo). In my recommended world, I would learn about
> /foo/* and /foo/bar/* now, too.
>

IMHO, the "split stuff that needs to be hidden to different repo"
workaround should be sufficient for now. Anything else requires lotsa
lotsa work to benefit the tiny minority of users that might need it.
They can offer a bounty or something.

-- Brane

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1314126
Received on 2009-03-12 20:38:19 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.