How to deal with #402010? - Debian

This is a discussion on How to deal with #402010? - Debian ; Hi, my position to this bug is written down in the bugtracker and I don't consider this a bug. Any opinions about what to do with it? It would apply to virtually any kind of web application accessing some kind ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: How to deal with #402010?

  1. How to deal with #402010?

    Hi,

    my position to this bug is written down in the bugtracker and I don't consider
    this a bug. Any opinions about what to do with it? It would apply to
    virtually any kind of web application accessing some kind of database/ldap
    passwords somewhere in the filesystem.

    This is a simulated problem - or maybe someone wants to implement built-in ACL
    support for (at least) the 4 major LDAP servers?

    Thanks,
    Cajus


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

  2. Re: How to deal with #402010?

    Cajus Pollmeier, 2008-04-04 09:18:37 +0200 :

    > Hi,
    >
    > my position to this bug is written down in the bugtracker and I
    > don't consider this a bug. Any opinions about what to do with it? It
    > would apply to virtually any kind of web application accessing some
    > kind of database/ldap passwords somewhere in the filesystem.


    Depending on the web server, there may be a way around that problem.
    The following works with Apache, at least, and I guess it can be
    adapted to other servers as well.

    The thing is to store the passwords or sensitive info in files that
    are only readable by root, and have Apache read these files and export
    the information selectively to some webapps and not others, by
    wrapping the appropriate directives in VirtualHost (or similar)
    blocks. Then it's a simple matter (ahem) of passing the info to the
    webapp, and there are two ways to do that: with SetEnv (not ideal) or
    with RequestHeader (probably better).

    Roland.
    --
    Roland Mas

    Et c'est tellement plus mignon de se faire traiter de con en chanson...
    -- in En chantant (Michel Sardou)


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

  3. Re: How to deal with #402010?

    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 mechanismto
    deal with the password then the current one.

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


    regards,
    Holger

    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 :-)

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQBH9fn0UHLQNqxYNSARAjE/AJ4osxAqXbug6W3pHWHfSUUMcG5VCwCgo9by
    XoSrQjomgdNteKUbmU5driw=
    =d+6/
    -----END PGP SIGNATURE-----


  4. 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-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  5. 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-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  6. Re: 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

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQBH90FdynjLPm522B0RAiRsAJ9OQMm7jU44WOchIK4/ITrGBMJngwCeKTgW
    a0vByWJ4R65MloIF1XsEcdk=
    =oAMX
    -----END PGP SIGNATURE-----


  7. Re: 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

    include /etc/gosa/gosa.secrets


    # 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

  8. Re: 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

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQBH902GynjLPm522B0RAt3MAKCHb5Ucj4pdlkEFE/6RT2L9SF5pMwCfcfkH
    3prlGamOsshgOLeUC/jTjEg=
    =TdZh
    -----END PGP SIGNATURE-----


  9. Re: 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

  10. Re: 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

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQBH+RxKynjLPm522B0RArvSAJ9e7B5+aPftvMDFzGscPf aE4uOOswCgiUks
    Ic8ZQxJ1uaf2XaNwcLwNiWM=
    =nmWI
    -----END PGP SIGNATURE-----


  11. Re: 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

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFH+Rhe2XtckeYvo1gRAjQXAJ9h/UhrP27QBAK+jgvNHoByQNQR5gCfdC1n
    cHAAzSgGeEswoBgCbilx0Qo=
    =N9af
    -----END PGP SIGNATURE-----


+ Reply to Thread