Doug Chestnut wrote:
Currently usecases get restrictive with policies in
usecase-policies.xml. Should we make usecase-policies.xml be permissive
instead (only allow usecase execution if a policy exists and the policy
is met). This would force us to think about policies when creating new
functionality.
+1
-- Andreas
--Doug
Andreas Hartmann wrote:
Doug Chestnut wrote:
Hi Joern,
The first thing to change would be to add
<usecase id="admin.changePassword">
<role id="admin"/>
</usecase>
to your (and our default pubs) pubs usecase-policies.xml
Exactly - and we could declare two different usecases so that one can
be permitted only for admins and the other one (with entering the old
password) for all users (see my other reply).
-- Andreas
--Doug
Joern Nettingsmeier wrote:
Jörn Nettingsmeier wrote:
i just realized we have a huuuuge security hole that affects every
lenya
1.4 installation:
* checkOldPassword is set by the (potentially hostile) client.
* the java code does not check that only admins may change
passwords for
other user-ids than the currently logged-in one.
ergo any user can change the passwords of arbitrary other users,
including admins. instant dos and privilege escalation, remotely
exploitable. not nice at all.
<..>
i will try to fix this on friday if no one gets to do it tomorrow.
hi guys! before i try to implement it, please comment on this new
policy
for changing passwords:
/**
* Usecase to change a user's password.
*/
public class UserPassword extends AccessControlUsecase {
/*
If the optional parameter "userId" is not set, we assume that the
password of the currently logged in user is to be changed.
Non-privileged users (i.e. those not belonging to the "admin"
group)
cannot set userId to another user, i.e. they can only ever change
their own passwords.
Privileged users (those in the admin group) can set userId, and
thus
change the passwords of other users.
All users will have to provide their own password again when they
try to change passwords, regardless of the fact that they are
already authenticated.
This is to protect users who leave their session unattended "for
just a second" from having their passwords changed by passers-by.
a formerly existing parameter "checkPassword", which could be
used to override this password check, has been abolished for
security reasons.
*/
as you see, this adds a very special meaning to the group "admin". is
that appropriate and in keeping with current usage? if so, i want to
make sure that this is sufficiently documented. where are the current
semantics of the admin group defined? (if the answer is "in the source
code somewhere", bzzzt, zero points.) what would be the best place to
define security semantics authoritatively?
regards,
jörn
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED] [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
