Hi folks,
the Python script "ldap_group.py" (among others) contains the master
LDAP admin password _hardcoded_ and is world-readable.
Thus everybody having shell-access to this machine can read the most
essential LDAP credits directly - and all the other ones are probably
having easy read access via Apache modules with known security holes,
because nobody of those who set this machine up had been taking care of
applying at least the most essential security fixes.
I wonder why people had been in favour of setting up that many
different VM's if they are incapable of maintaining all these machines
and don't understand at least the basics of IT security.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
On Tue, Apr 10, 2012 at 12:28:58AM +0200, Martin Spott wrote:
the Python script "ldap_group.py" (among others) contains the master
LDAP admin password _hardcoded_ and is world-readable.
Ah, btw, as an immediate measure, I've changed these files to 640. As a
consequence they probably don't work today.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
On Mon, Apr 9, 2012 at 3:28 PM, Martin Spott <Martin.Spott@mgras.net> wrote:
Hi folks,
the Python script "ldap_group.py" (among others) contains the master
LDAP admin password _hardcoded_ and is world-readable.
Martin,
It would be helpful to specify what system this is on.
Thus everybody having shell-access to this machine can read the most
essential LDAP credits directly - and all the other ones are probably
having easy read access via Apache modules with known security holes,
because nobody of those who set this machine up had been taking care of
applying at least the most essential security fixes.
I wonder why people had been in favour of setting up that many
different VM's if they are incapable of maintaining all these machines
and don't understand at least the basics of IT security.
...
Ah, btw, as an immediate measure, I've changed these files to 640. As a
consequence they probably don't work today.
I have confirmed you have broken the scripts. So how shall we deal with
this? Shall I just change it back? Or should I just go off in a huff in the
face of your actions?
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Software Developer
Hi folks,
the Python script "ldap_group.py" (among others) contains the master
LDAP admin password _hardcoded_ and is world-readable.
Thus everybody having shell-access to this machine can read the most
essential LDAP credits directly - and all the other ones are probably
having easy read access via Apache modules with known security holes,
because nobody of those who set this machine up had been taking care of
applying at least the most essential security fixes.
I wonder why people had been in favour of setting up that many
different VM's if they are incapable of maintaining all these machines
and don't understand at least the basics of IT security.
Cheers,
Martin.
The general purpose of the separation by vm is to prevent problems on one machine from encroaching on others and allow finer grained security (meaning groups can be given access to one without access to all). As is the case here, the machines with major LDAP functionality are not open to people outside of SAC and those are the people we want to be able to read that file. As for ensuring it can't be sniffed via apache exploits we should look into a solution.
I think you raise a good point and we should consider doing automatic security updates or a scheduled time each month. The biggest problem that poses is not doing major kernel upgrades on machines sensitive to changes in the kernel related to compiling (unlikely) or other custom built things with various version specific deps. Do you know how to implement auto security patching via apt preferences (Ubuntu has this option at install and I've read you can implement it after the fact)?
Based on that I would say everything but Projects and Adhoc could move to this auto-update option without much review.
In the future an email before disabling a major service except in the case of protection against and active problem (active hack,disk dying, etc,overheating servers, etc...) would be appreciated.
Thanks,
Alex
PS: Anyone else from SAC @ FOSS4G-na so we can talk in person about issues?