Re: DO NOT REPLY - AC Auth controls admin area

>> hmm. i don't like this patch at this point in
tíme.
>> if i understand richard correctly, he has been
handing out the admin
>> role to users, thinking that they are limited to
the subtree they are
>> given. but this opens the hole that a user can
browse there and then
>> call admin usecases to escalate his/her privileges.
if this is correct,
>> read on, otherwise i've misunderstood something, so
ignore me.
>>
>> i think this is basically a documentation bug.
what's needed for this
>> usage scenario is a new role like you introduced,
but this is something
>> that users can do themselves, tailored to their
needs. why do we need a
>> new method (e.g. a *fundamental* change to the AC
API), and why should 
>> everyone have to update their policies during code
freeze?
> 
> You are somewhat correct. It is a question of
functionality. In my usage 
> scenario, it makes sense to give a user the rights to
change ac auth for 
> their subtree, or allow them to change a node name or
visibility of a 
> node. Without the patch, I can't do that.
> 
> Let's say it is a documentation issue and we want to
allow that 
> functionality. I then allow reviewers the rights to
those usecases. They 
> can then go into ac auth, give themselves admin rights.
Presto, they can 
> get into the admin area.
> 
> So basically, we need the additional method to protect
against this sort 
> of thing so that the admin role can't be assigned via
ac auth. Or we 
> have to hack the code to make it so that ac auth, ac
archive, ac trash 
> only allow admins and no other roles. That would mean
hacking the 
> usecases admin interface to prevent this. I think this
was a clean fix 
> to a dirty security issue.

hmm, ok, thanks for explaining again. i'm getting a little
more insight 
now. but i think the correct approach in the current
situation is to 
graft on a custom usecase that does what you need done, and
disallows 
privilege escalation [1]. i'm really uneasy with fundamental
ac 
semantics changes in a hurry during code freeze.



[1] of course, this can't just be an alternate *view*,
because then the 
user can tamper with the form data and effect privilege
escalation 
nonetheless (we used to have that situation with the
password changing 
usecase iirc).
-- 
Jörn Nettingsmeier

"One of my most productive days was throwing away 1000
lines of code."
   - Ken Thompson.

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

Jörn Nettingsmeier wrote:
>>> hmm. i don't like this patch at this point in
tíme.
>>> if i understand richard correctly, he has been
handing out the admin
>>> role to users, thinking that they are limited
to the subtree they are
>>> given. but this opens the hole that a user can
browse there and then
>>> call admin usecases to escalate his/her
privileges. if this is correct,
>>> read on, otherwise i've misunderstood
something, so ignore me.
>>>
>>> i think this is basically a documentation bug.
what's needed for this
>>> usage scenario is a new role like you
introduced, but this is something
>>> that users can do themselves, tailored to their
needs. why do we need a
>>> new method (e.g. a *fundamental* change to the
AC API), and why 
>>> should everyone have to update their policies
during code freeze?
>>
>> You are somewhat correct. It is a question of
functionality. In my 
>> usage scenario, it makes sense to give a user the
rights to change ac 
>> auth for their subtree, or allow them to change a
node name or 
>> visibility of a node. Without the patch, I can't do
that.
>>
>> Let's say it is a documentation issue and we want
to allow that 
>> functionality. I then allow reviewers the rights to
those usecases. 
>> They can then go into ac auth, give themselves
admin rights. Presto, 
>> they can get into the admin area.
>>
>> So basically, we need the additional method to
protect against this 
>> sort of thing so that the admin role can't be
assigned via ac auth. 
>> Or we have to hack the code to make it so that ac
auth, ac archive, 
>> ac trash only allow admins and no other roles. That
would mean 
>> hacking the usecases admin interface to prevent
this. I think this 
>> was a clean fix to a dirty security issue.
>
> hmm, ok, thanks for explaining again. i'm getting a
little more 
> insight now. but i think the correct approach in the
current situation 
> is to graft on a custom usecase that does what you need
done, and 
> disallows privilege escalation [1]. i'm really uneasy
with fundamental 
> ac semantics changes in a hurry during code freeze.

The problem is the core code has no method of preventing
privilege 
escalation. This is a severe fundamental vulnerability and
it needs to 
be fixed before being released. So I would need to override
the existing 
ac auth, ac archive, ac trash usecases to prevent the admin
role from 
being assigned. And after all of that, only I am protected,
provided I 
wrote my code good enough to block the core problem. What
about the 
average user? It is currently trivial (without the patch) to
take alice 
and make her admin due to how the default pub is shipped.

I agree it isn't good to have ac changes now. However, it's
even worse 
to ship with this vulnerability.

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org