Hi SAC,
On Wed, Dec 19, 2007 at 11:19:40AM -0800, Tyler Mitchell (OSGeo) wrote:
By giving the module access to the LDAP manager role, it can now
allows users to reset their passwords and edit their own attributes.
There is always concern about using the manager role in the
application, but largely because we didn't really understand how it
gets used in Drupal. Now, the password itself does not appear in
cleartext in any form in drupal, though it is stored in the database.
I still have serious concerns about doing so, I consider this as a
design flaw that could be avoided (see below).
A complex content management system running in PHP translates into some
of the most prominent components which make an invitation to hacking
the site. This is considered to be well-known consensus, not only since
Stefan Esser started the "Month of PHP Bugs" initiative which made the
whole issue even more popular.
This means, that everyone who gains access to the OSGeo web service
(Apache) permissions via some PHP flaw or, not to forget, a possible
Drupal security bug and who has a certain knowledge about the LDAP
module which we are using here, has the ability to get unlimited
access to the _complete_ OSGeo user management.
This is really scaring !!!
I find this even more irritating because we're putting the whole LDAP
directory at risk for a reason that could be avoided because you
definitely do _not_ need LDAP Manager access to change the first name
or the password of your already existing entry in an LDAP directory.
You just need to set proper LDAP ACL's and bind to the directory as the
respective user.
In fact, the core problem is a totally different one. For some reason
that I mostly have forgotten, we still don't apply LDAP ACL's to our
directory. As far as my memory serves we had some Trac authentication
issues when ACL's were in place - Trac's LDAP authentication probably
was incapable of binding to the directry server as a regular user.
So, this is my simplified proposal about how to make the OSGeo LDAP
service a bit safer:
1.) Remove the LDAP Manager permissions from Drupal first;
2.) enable reasonable LDAP ACL's and, just in case this still proves to
be necessary:
3.) fix broken LDAP clients;
4.) make the Drupal LDAP module bind to the directory as regular user
only;
5.) while we are at it: completely disable unencrypted access to the
LDAP directory;
6.) disable unencrypted HTTP logins on _all_ sites that authenticate
against the OSGeo LDAP service;
7.) add an appropriate field in the LDAP user entry, request all Wiki
users to create an OSGeo login and to enter their current Wiki user
name .... this could relieve us from the need to manually
correllate Wiki to OSGeo user accounts 
Well, 2.) and 3.) could be swapped ....
I know that this EMail might sound a bit harsh. Yet I think this is
unavoidable to make it clear to which risk our LDAP service is
currently exposed. As long as we consider this LDAP service at the core
OSGeo user authentication, this significantly diverges from the rather
conservative maintenance conventions that usually apply to OSGeo's
other core services.
Concerns, opinions ?
Best regards,
Martin.
P.S.: Did you know that 'osgeo1' shares a DNS entry '66.223.95.245' with
'webmail.danvillestation.com' ? 
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
I'll have to check if I can find a module which could expand