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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
