You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by bu...@apache.org on 2007/11/20 18:08:05 UTC
DO NOT REPLY [Bug 43915] New: - AC Auth controls admin area
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43915>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43915
Summary: AC Auth controls admin area
Product: Lenya
Version: Trunk
Platform: Other
OS/Version: other
Status: NEW
Severity: blocker
Priority: P2
Component: Access Control
AssignedTo: dev@lenya.apache.org
ReportedBy: rfrovarp@apache.org
One of my testers has found an easy way to escalate rights in Lenya. If someone
has admin rights to a subtree, they can use these rights to gain full access to
the admin tab. This is not desirable as one would grant admin on a subtree so
that the sub-admin can administer rights on that subtree.
To replicate:
Login as lenya
Grant editor group admin to editors under AC Auth from index
Logout
Login as alice
Goto admin tab
Create users
Go back to site
Change to sibling of index/home
Go back to admin, you will now be blocked (so long as you didn't add alice to
admin group, which you easily could have).
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
DO NOT REPLY [Bug 43915] - AC Auth controls admin area
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43915>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43915
rfrovarp@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|2.0.1 |2.0
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
DO NOT REPLY [Bug 43915] - AC Auth controls admin area
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43915>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43915
------- Additional Comments From andreas@apache.org 2007-11-20 09:20 -------
Strange, why isn't this blocked by the usecase policies? The per-URL protection
of the admin area is obsolete. Actually there should be no admin area anymore.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
DO NOT REPLY [Bug 43915] - AC Auth controls admin area
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43915>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43915
------- Additional Comments From andreas@apache.org 2007-11-21 03:08 -------
(In reply to comment #6)
> (In reply to comment #5)
> >
> >
> > IMO this would mean that we need two "administrator" roles:
> >
> > - a website administrator who is allowed to grant/deny roles etc.
> > - an application administrator who is allowed to execute the admin.* usecases
>
> That could work. We obviously wouldn't want to give editors the rights to
> tab.ac*. And giving reviewers the rights doesn't make sense either. So it would
> appear that we do need another role.
I'm working on it.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
DO NOT REPLY [Bug 43915] - AC Auth controls admin area
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43915>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43915
andreas@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |FIXED
------- Additional Comments From andreas@apache.org 2007-11-21 05:04 -------
OK, now it should really be fixed.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
DO NOT REPLY [Bug 43915] - AC Auth controls admin area
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43915>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43915
------- Additional Comments From andreas@apache.org 2007-11-20 09:26 -------
(In reply to comment #2)
> Strange, why isn't this blocked by the usecase policies? The per-URL protection
> of the admin area is obsolete. Actually there should be no admin area anymore.
Ah, of course, if the PolicyManager grants the roles, the usecase policies are
complied.(In reply to comment #3)
> (In reply to comment #2)
> > Strange, why isn't this blocked by the usecase policies? The per-URL protection
> > of the admin area is obsolete. Actually there should be no admin area anymore.
>
> Well, this method is granting a group a role of admin,and usecase policies only
> looks at roles, not groups.
Of course, sorry for my stupid remark :)
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: DO NOT REPLY [Bug 43915] - AC Auth controls admin area
Posted by Andreas Hartmann <an...@apache.org>.
Jörn Nettingsmeier schrieb:
> bugzilla@apache.org wrote:
[...]
>> ------- Additional Comments From andreas@apache.org 2007-11-21 03:17
>> ------- I introduced a method Role.isAssignable() and a role
>> "sitemanager" with a group of the same name. All users have to update
>> their policies accordingly.
>>
>> Please test and re-open if this doesn't resolve the issue. TIA!
>
> 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),
The system can't allow the sitemanager users to assign admin roles to
themselves.
> and why should everyone have to update their policies during code freeze?
To avoid this, we could add some code that checks the existing policies
for non-assignable roles and removes them when they are loaded.
> sorry if i've had a lot of criticism to offer lately, and not much help,
You're kidding :)
> but i'm drowning in work... i think we should tie up what we have and
> not get into any new things that are not really bugfixes.
I gave it some thoughts over the night and didn't find a better
solution, and I felt rather urged to fix the blocker so that we could
prepare the second RC. But of course you are right that we have to be
careful, and I'm glad that you started this discussion. Thanks! :)
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: DO NOT REPLY [Bug 43915] - AC Auth controls admin area
Posted by Jörn Nettingsmeier <ne...@apache.org>.
Richard Frovarp wrote:
> Jörn Nettingsmeier wrote:
>> 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.
handing out the admin role is what allows privilege escalation.
i see what your problem is, and it surely needs to be solved in trunk.
but i'm still not convinced we should introduce fundamentally new role
semantics when all we need is a new usecase that allows users to grant a
configurable subset of roles.
ideally only those they own themselves (the WITH GRANT OPTION from SQL
land) - although this can also lead to escalation if two rogue
maintainers join forces, but we can ignore this threat imho.
> 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.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
actually, i find this quite obvious, but you are right, our tree-based
roles easily make people expect otherwise. that is a documentation
issue. or else, all our ac usecases have to be made tree context
sensitive so that they behave as people would expect.
> 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.
agreed. i'm just not convinced it should be handled via new roles semantics.
> I know I
> don't have any say over the manner, but from my experience with Lenya
> being deployed that's how I feel.
well, you have certainly as much say about this as yours truly. if
everyone else thinks this approach is ok, i'm accepting it. hell, it's
not as if i have tried to implement a really good solution myself yet,
so talk is cheap. i just feel we've been a bit too easy in the past with
introducing fundamentally new features to quickly solve the issue of the
day, and excuse my french but it has lead to a bloody fscking mess.
if despite my heckling everyone still thinks it's the approach to go
for, that's fine. i just want to make sure that everybody has considered
the implications of new role semantics vs. just writing a new usecase.
> 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.
as i said, if you still think it's appropriate, i'm trusting your
judgement. i don't have time atm to come up with something simpler, and
you obviously need this thing fixed, so go ahead.
--
Jörn Nettingsmeier
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: DO NOT REPLY [Bug 43915] - AC Auth controls admin area
Posted by Richard Frovarp <ri...@sendit.nodak.edu>.
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-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: DO NOT REPLY [Bug 43915] - AC Auth controls admin area
Posted by Jörn Nettingsmeier <ne...@apache.org>.
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-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: DO NOT REPLY [Bug 43915] - AC Auth controls admin area
Posted by Richard Frovarp <Ri...@sendit.nodak.edu>.
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-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: DO NOT REPLY [Bug 43915] - AC Auth controls admin area
Posted by Jörn Nettingsmeier <ne...@apache.org>.
>> 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-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: DO NOT REPLY [Bug 43915] - AC Auth controls admin area
Posted by Richard Frovarp <Ri...@sendit.nodak.edu>.
Jörn Nettingsmeier wrote:
> bugzilla@apache.org wrote:
>> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED
>> COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
>> <http://issues.apache.org/bugzilla/show_bug.cgi?id=43915>. ANY REPLY
>> MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG
>> DATABASE.
>>
>> http://issues.apache.org/bugzilla/show_bug.cgi?id=43915
>>
>>
>> andreas@apache.org changed:
>>
>> What |Removed |Added
>> ----------------------------------------------------------------------------
>>
>> Status|NEW |RESOLVED Resolution|
>> |FIXED
>>
>>
>>
>>
>> ------- Additional Comments From andreas@apache.org 2007-11-21 03:17
>> ------- I introduced a method Role.isAssignable() and a role
>> "sitemanager" with a group of the same name. All users have to update
>> their policies accordingly.
>>
>> Please test and re-open if this doesn't resolve the issue. TIA!
>
> 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?
>
> sorry if i've had a lot of criticism to offer lately, and not much help,
> but i'm drowning in work... i think we should tie up what we have and
> not get into any new things that are not really bugfixes.
>
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.
Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: DO NOT REPLY [Bug 43915] - AC Auth controls admin area
Posted by Jörn Nettingsmeier <ne...@apache.org>.
bugzilla@apache.org wrote:
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED
> COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> <http://issues.apache.org/bugzilla/show_bug.cgi?id=43915>. ANY REPLY
> MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG
> DATABASE.
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=43915
>
>
> andreas@apache.org changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> Status|NEW |RESOLVED Resolution|
> |FIXED
>
>
>
>
> ------- Additional Comments From andreas@apache.org 2007-11-21 03:17
> ------- I introduced a method Role.isAssignable() and a role
> "sitemanager" with a group of the same name. All users have to update
> their policies accordingly.
>
> Please test and re-open if this doesn't resolve the issue. TIA!
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?
sorry if i've had a lot of criticism to offer lately, and not much help,
but i'm drowning in work... i think we should tie up what we have and
not get into any new things that are not really bugfixes.
--
Jörn Nettingsmeier
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
DO NOT REPLY [Bug 43915] - AC Auth controls admin area
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43915>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43915
andreas@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Additional Comments From andreas@apache.org 2007-11-21 03:17 -------
I introduced a method Role.isAssignable() and a role "sitemanager" with a group
of the same name. All users have to update their policies accordingly.
Please test and re-open if this doesn't resolve the issue. TIA!
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
DO NOT REPLY [Bug 43915] - AC Auth controls admin area
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43915>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43915
------- Additional Comments From andreas@apache.org 2007-11-20 09:30 -------
(In reply to comment #0)
> One of my testers has found an easy way to escalate rights in Lenya. If someone
> has admin rights to a subtree, they can use these rights to gain full access to
> the admin tab. This is not desirable as one would grant admin on a subtree so
> that the sub-admin can administer rights on that subtree.
IMO this would mean that we need two "administrator" roles:
- a website administrator who is allowed to grant/deny roles etc.
- an application administrator who is allowed to execute the admin.* usecases
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
DO NOT REPLY [Bug 43915] - AC Auth controls admin area
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43915>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43915
------- Additional Comments From rfrovarp@apache.org 2007-11-20 09:23 -------
(In reply to comment #2)
> Strange, why isn't this blocked by the usecase policies? The per-URL protection
> of the admin area is obsolete. Actually there should be no admin area anymore.
Well, this method is granting a group a role of admin,and usecase policies only
looks at roles, not groups.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
DO NOT REPLY [Bug 43915] - AC Auth controls admin area
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43915>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43915
andreas@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
------- Additional Comments From andreas@apache.org 2007-11-21 03:20 -------
I forgot to check for URL manipulation attacks.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
DO NOT REPLY [Bug 43915] - AC Auth controls admin area
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43915>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43915
------- Additional Comments From rfrovarp@apache.org 2007-11-20 09:11 -------
It would appear that the problem is admin is typically under the authoring
subtree. There is an admin subtree-policy.acml, however the URL is never
switched over to that area. Manually switching authoring to admin does work,
however the authoring tab changes name to admin and the site tab stays in the
admin area as well.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
DO NOT REPLY [Bug 43915] - AC Auth controls admin area
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43915>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43915
------- Additional Comments From rfrovarp@apache.org 2007-11-20 09:42 -------
(In reply to comment #5)
>
>
> IMO this would mean that we need two "administrator" roles:
>
> - a website administrator who is allowed to grant/deny roles etc.
> - an application administrator who is allowed to execute the admin.* usecases
That could work. We obviously wouldn't want to give editors the rights to
tab.ac*. And giving reviewers the rights doesn't make sense either. So it would
appear that we do need another role.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org