Re: DO NOT REPLY - AC Auth controls admin area

Richard Frovarp wrote:
> Jörn Nettingsmeier wrote:
>>> 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.

i still don't really understand the problem. iiuc, you want
to allow 
some of your users to access some usecases. of course, these
usecases 
must not include any that allow privilege escalation. now
all you need 
to do is introduce a new role "maintenance" or
whatever, which is then 
granted access to whatever usecases you need.
if this includes one that would allow privilege escalation,
you will 
have to write a slightly modified usecase that avoids this
problem.

won't that solve your issue?

i agree we could think about this some more and provide a
generally 
useful solution, but only after it has been demonstrated to
this bear of 
very little brain that there really is a general problem,
and only after 
2.0.

-- 
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:
> Richard Frovarp wrote:
>>
>> 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.
>
> i still don't really understand the problem. iiuc, you
want to allow 
> some of your users to access some usecases. of course,
these usecases 
> must not include any that allow privilege escalation.
now all you need 
> to do is introduce a new role "maintenance"
or whatever, which is then 
> granted access to whatever usecases you need.
> if this includes one that would allow privilege
escalation, you will 
> have to write a slightly modified usecase that avoids
this problem.
>
> won't that solve your issue?
>
> i agree we could think about this some more and provide
a generally 
> useful solution, but only after it has been
demonstrated to this bear 
> of very little brain that there really is a general
problem, and only 
> after 2.0.
>
The problem is that AC Authoring, AC Trash, and AC Archive
all allow 
privilege escalation. There are two very large problems with
this.

1) It is quite advantageous to allow an admin to partition
control over 
AC Authoring out over parts of subtrees to individuals who
may not be 
admins fo the entire site. There is no way to do this
without a fix. For 
example go to Archive, then AC Archive with alice. From
there (without 
the patch) you could give yourself the admin role. After you
have the 
admin role, you can just click on ADMIN and away you go with
full admin 
rights.

2) If we don't want people to partition control over AC
Authoring out to 
other users we have a HUGE documentation nightmare. The real
admins 
obviously still need to get to AC Auth to partition out edit
and review 
roles. They have to be told to never ever ever ever under
any 
circumstances to grant someone the admin role. I found this
bug because 
one of my users denied the admin group the admin role on
their index 
page. So if you believe that admins will never assign the
admin role 
under AC Auth (if the option is presented to them), well I
think I have 
a bridge for you, or your users are a lot more
technologically 
sophisticated than mine.

And why should I have to write a modified usecase to avoid
the problem 
when it's a core problem that EVERY deployment will have.
I'm guessing 
we want to deploy this to locations that don't have Lenya
devs on staff. 
So we need to fix this problem and it needs to be before
2.0. I know I 
don't have any say over the manner, but from my experience
with Lenya 
being deployed that's how I feel.

Andreas' patches are really quite minimal if you look at it.
r597037 
just makes it so that you can set roles that are not
assignable. r597055 
prevents circumvention of this by URL manipulation. They are
a clean and 
simple fix to the problem. However, they are such that any
publication 
already deployed will require some changes. Upgrading from
2.0 to 2.0.1 
should be a simple matter.

I have not done large scale testing of the fix, but all of
my testing 
has been with the patch in place and have not found any
issues.

Richard

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