Bug#402010: How to deal with #402010?
 

Am Freitag, 4. April 2008 11:50:42 schrieb Holger Levsen:
> Hi,
>
> On Friday 04 April 2008 09:18, Cajus Pollmeier wrote:
> > to virtually any kind of web application accessing some kind of
> > database/ldap passwords somewhere in the filesystem.
>
> I dont consider a web application which is used to configure the LDAP
> database and FAI configuration (to install and configure all machines in
> the network) just like any other web application.
>
> In this bug are several suggestions how to implement a way better mechanism
> to deal with the password then the current one.

If you read the comments, I'll see that it is not possible to use these
suggestions. Besides maybe the last one, but there's no propper
infrastructure in debian to use it directly.

> Also I unarchived this bug, because I think the least you can and should do
> is to document this in the README.Debian. (This=dont allow public html dirs
> for users and leave safe mode on.)

As said - I'm not responsible for the webserver setup of other people. Sure, I
can put it inside the README and close this bug - waiting until the next one
comes around and urges me to do something about it again. Ah wait, I can just
orphan the gosa packages.

> P.S.: regarding those four major ldap servers.. I think it would be a great
> start if it would be more secure with one of them :-)

You're welcome. Send patches.

Cheers,
Cajus


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Bug#402010: How to deal with #402010?
 

On Fri, Apr 04, 2008 at 12:22:05PM +0200, Cajus Pollmeier wrote:
> As said - I'm not responsible for the webserver setup of other people.
> Sure, I can put it inside the README and close this bug - waiting
> until the next one comes around and urges me to do something about it
> again. Ah wait, I can just orphan the gosa packages.

Better to leave it open and tag it wontfix (meaning "can't fix") if the
bug is not actually fixed.


--
Jon Dowland


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Bug#402010: How to deal with #402010?
 

hi,

a few more ideas for you to think about:

- create a user specific to the package, and

1: use a setuid wrapper binary for doing all ldap communications

or

2: use some kind of user-restricted fastcgi type setup instead of standard
apache mod_php/python/whatever

or

3: run a seperate instance of $webserver listening on a different port
(localhost:8080 or similar), and running as the specific user. you can then
drop in a proxy config to make that available from the standard $webserver.




sean

Bug#402010: How to deal with #402010?
 

The problem is that these aspects are not packagable as some kind of
"fire and forget" installation. I'd prefer the way Roland proposed,
using some kind of


# cat /etc/apache2/conf.d/gosa.conf
Alias /gosa /usr/share/gosa/html
<Location /gosa>
include /etc/gosa/gosa.secrets
</Location>

# cat /etc/gosa/gosa.secrets
RequestHeader set FooPassword very-secret-credentials

The latter file can only be read by root, so the security "problem" is
as critical as beeing able to read cleartext kerberos or sasldb
passwords as root.


This implementation only requires minimum changes and has no big
overhead on the server side... Uh, and a "a2enmod headers" from
postinst.


Cheers,
Cajus

Am 05.04.2008 um 11:07 schrieb sean finney:

hi,

a few more ideas for you to think about:

- create a user specific to the package, and

1: use a setuid wrapper binary for doing all ldap communications

or

2: use some kind of user-restricted fastcgi type setup instead of
standard

apache mod_php/python/whatever

or

3: run a seperate instance of $webserver listening on a different port
(localhost:8080 or similar), and running as the specific user. you
can then
drop in a proxy config to make that available from the standard
$webserver.





sean



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Bug#402010: How to deal with #402010?
 

hi,

On Saturday 05 April 2008 11:26:14 am Cajus Pollmeier wrote:
> The problem is that these aspects are not packagable as some kind of
> "fire and forget" installation. I'd prefer the way Roland proposed,
> using some kind of

option 3 could work out of the box, though it just requires more initial setup
work to get right in the packaging. i'm not saying it's the Right Way, but
it would provide the necessary compartmentalizing.

> RequestHeader set FooPassword very-secret-credentials

i suspect php users will still be able to find that out, in the same way that
they can read ssl private keys from the webserver's memory (you *did* know
they can do that, right? :)

sean

Bug#402010: How to deal with #402010?
 

sean finney, 2008-04-05 11:59:31 +0200 :

[...]

>> RequestHeader set FooPassword very-secret-credentials
>
> i suspect php users will still be able to find that out, in the same
> way that they can read ssl private keys from the webserver's memory
> (you *did* know they can do that, right? :)

Erm, no, I didn't. Is that supposed to happen (by design), or is it
just a bug in the PHP interpreter? It sounds like a severe security
problem...

Roland.
--
Roland Mas

Au royaume des aveugles, il y a des borgnes à ne pas dépasser.
-- in Soeur Marie-Thérèse des Batignoles (Maëster)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Bug#402010: How to deal with #402010?
 

On Sun Apr 06 17:32, Roland Mas wrote:
> sean finney, 2008-04-05 11:59:31 +0200 :
>
> [...]
>
> >> RequestHeader set FooPassword very-secret-credentials
> >
> > i suspect php users will still be able to find that out, in the same
> > way that they can read ssl private keys from the webserver's memory
> > (you *did* know they can do that, right? :)
>
> Erm, no, I didn't. Is that supposed to happen (by design), or is it
> just a bug in the PHP interpreter? It sounds like a severe security
> problem...

If you use mod_php then your process is running with the same uid as the
web server, ergo, it can read the memory of the apache process. The php
interpreter doesn't have much to do with it, as long as system() and
friends are enabled.

Matt
--
Matthew Johnson

Bug#402010: How to deal with #402010?
 

heya,

On Sunday 06 April 2008 05:32:39 pm Roland Mas wrote:
> > i suspect php users will still be able to find that out, in the same
> > way that they can read ssl private keys from the webserver's memory
> > (you *did* know they can do that, right? :)
>
> Erm, no, I didn't. Is that supposed to happen (by design), or is it

by apache's design, any loaded module (like mod_php, mod_python, etc) can read
the memory contents of the apache process. i think they make the assumption
that since the admin won't intentionally load an evil apache module that this
isn't a problem. however, if one of the modules (via vulnerability or poor
design) allows such access, then you're still in this situation.

they (apache devs) could of course make this a non-issue by compartmentalizing
things (i.e. have a seperate process/uid for doing ssl encoding/decoding),
but my guess is that this was either not a concern and/or too much work
and/or too much performance cost to be done the Right Way.

> just a bug in the PHP interpreter? It sounds like a severe security
> problem...

the... ehem... "history" of the php interpreter is that it is often easy to
leverage small bugs and design flaws to get this information. however, i
don't think this is php-specific. if someone has a system configured with
mod_python that i could play with, i might be able to verify that :)


sean