• =?UTF-8?Q?N=27importe_que_utilisateur_peut_faire_tourner_l=27interp?= =

    From Bernard Bass@21:1/5 to All on Wed Oct 2 17:50:01 2024
    This is a multi-part message in MIME format.
    Bonjour,

    J'ai voulu "protéger" un fichier.php en le donnant à mon utilisateur
    sudoer, que j'utilise pour administrer la machine.
    Sans élévation de droit, il s'agit d'un simple utilisateur lambda.

    Je suis étonné de voir que le fichier.php est tout de même interprété. Est-ce normal ?

    <!DOCTYPE html>
    <html>
    <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    </head>
    <body text="#000000" bgcolor="#929292">
    <p>Bonjour,<br>
    <br>
    J'ai voulu "protéger" un fichier.php en le donnant à mon
    utilisateur sudoer, que j'utilise pour administrer la machine.<br>
    Sans élévation de droit, il s'agit d'un simple utilisateur lambda.<br>
    <br>
    Je suis étonné de voir que le fichier.php est tout de même
    interprété.<br>
    Est-ce normal ?<br>
    </p>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bernard Bass@21:1/5 to All on Wed Oct 2 18:10:02 2024
    This is a multi-part message in MIME format.
    Bonjour,

    J'ai voulu "protéger" un fichier.php en le donnant à mon utilisateur sudoer, que j'utilise pour administrer la machine.
    Sans élévation de droit, il s'agit d'un simple utilisateur lambda.

    Je suis étonné de voir que le fichier.php est tout de même interprété. Est-ce normal ?

    J'ai mis ces lignes pour interdire l'interprétation du fichier mais ce n'était pas l'idée.
    J'aurais aussi pu refuser l'accès complet depuis le virtualhost.

    <?php
    header("HTTP/1.0 403 Forbidden");
    header("HTTP/1.1 403 Forbidden");
    header("HTTP/2 403 Forbidden");


    Il me semblait que les simples utilisateurs ne pouvaient pas faire
    tourner php ce qui laissait les scripts non fonctionnels.
    J'ai loupé quelque chose ?

    <!DOCTYPE html>
    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body text="#000000" bgcolor="#929292">
    <blockquote type="cite"
    cite="mid:c8e29647-57bc-4d36-aec5-c9e2d10c25ed@visionduweb.com">
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <p>Bonjour,<br>
    <br>
    J'ai voulu "protéger" un fichier.php en le donnant à mon
    utilisateur sudoer, que j'utilise pour administrer la machine.<br>
    Sans élévation de droit, il s'agit d'un simple utilisateur
    lambda.<br>
    <br>
    Je suis étonné de voir que le fichier.php est tout de même
    interprété.<br>
    Est-ce normal ?<br>
    </p>
    </blockquote>
    <p>J'ai mis ces lignes pour interdire l'interprétation du fichier
    mais ce n'était pas l'idée.<br>
    J'aurais aussi pu refuser l'accès complet depuis le virtualhost.<br>
    </p>
    <p>&lt;?php<br>
    header("HTTP/1.0 403 Forbidden");<br>
    header("HTTP/1.1 403 Forbidden");<br>
    header("HTTP/2 403 Forbidden");<br>
    ?&gt;<br>
    <br>
    Il me semblait que les simples utilisateurs ne pouvaient pas faire
    tourner php ce qui laissait les scripts non fonctionnels.<br>
    J'ai loupé quelque chose ?<br>
    </p>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bernard Bass@21:1/5 to All on Wed Oct 2 18:30:01 2024
    This is a multi-part message in MIME format.
    J'ai tenté un chmod 000 pour voir si ça fonctionne encore, et bien oui,
    le fichier est toujours interprété et affiche HELLO.

    Bonjour, je pense que oui car le fichier php n'est pas un binaire. Il
    a besoin de l'interpréteur PHP qui n'est pas limité aux sudoers. Du
    moment que le fichier php est accessible en lecture par
    l'interpréteur, il sera interprété et exécuté


    Le mer. 2 oct. 2024 à 17:42, Bernard Bass
    <bernard.bass@visionduweb.com> a écrit :

    Bonjour,

    J'ai voulu "protéger" un fichier.php en le donnant à mon
    utilisateur sudoer, que j'utilise pour administrer la machine.
    Sans élévation de droit, il s'agit d'un simple utilisateur lambda.

    Je suis étonné de voir que le fichier.php est tout de même interprété.
    Est-ce normal ?

    <!DOCTYPE html>
    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body text="#000000" bgcolor="#929292">
    <blockquote type="cite" cite="mid:CALA8O7qFO4N=UWT+yGUiUXSj=Riwu_kZOjxCNzjXv0ysyyUcXw@mail.gmail.com">
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    </blockquote>
    J'ai tenté un chmod 000 pour voir si ça fonctionne encore, et bien
    oui, le fichier est toujours interprété et affiche HELLO.<br>
    <blockquote type="cite" cite="mid:CALA8O7qFO4N=UWT+yGUiUXSj=Riwu_kZOjxCNzjXv0ysyyUcXw@mail.gmail.com">
    <p dir="ltr">Bonjour, je pense que oui car le fichier php n'est
    pas un binaire. Il a besoin de l'interpréteur PHP qui n'est pas
    limité aux sudoers. Du moment que le fichier php est accessible
    en lecture par l'interpréteur, il sera interprété et exécuté </p>
    <br>
    <div class="gmail_quote">
    <div dir="ltr" class="gmail_attr">Le mer. 2 oct. 2024 à 17:42,
    Bernard Bass &lt;<a href="mailto:bernard.bass@visionduweb.com"
    moz-do-not-send="true" class="moz-txt-link-freetext">bernard.bass@visionduweb.com</a>&gt;
    a écrit :<br>
    </div>
    <blockquote class="gmail_quote"
    style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
    <div text="#000000" bgcolor="#929292">
    <p>Bonjour,<br>
    <br>
    J'ai voulu "protéger" un fichier.php en le donnant à mon
    utilisateur sudoer, que j'utilise pour administrer la
    machine.<br>
    Sans élévation de droit, il s'agit d'un simple utilisateur
    lambda.<br>
    <br>
    Je suis étonné de voir que le fichier.php est tout de même
    interprété.<br>
    Est-ce normal ?<br>
    </p>
    </div>
    </blockquote>
    </div>
    </blockquote>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From ajh-valmer@21:1/5 to All on Wed Oct 2 19:10:02 2024
    On Wednesday 02 October 2024 17:26:01 Bernard Bass wrote:
    J'ai voulu "protéger" un fichier.php en le donnant à mon utilisateur
    sudoer, que j'utilise pour administrer la machine.
    Sans élévation de droit, il s'agit d'un simple utilisateur lambda.
    Je suis étonné de voir que le fichier.php est tout de même interprété.
    Est-ce normal ?

    Mes fichiers Web .php se trouvent sous le répertoire html :
    -rw-rw-r-- propriétaire 33 , groupe 1004.

    Normalement, on les met dans le répertoire /var/www/
    user : www-data groupe : www-data
    dans ce mode : -rw- rw- r--

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bernard Bass@21:1/5 to All on Wed Oct 2 20:10:02 2024
    This is a multi-part message in MIME format.
    Maintenant tu parles de virtual host, ce qui implique Apache..

    Il faut éclaircir cela. Comment est appelé ton script ? Via une page web ?

    Oui depuis le navigateur.
    <!DOCTYPE html>
    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body text="#000000" bgcolor="#929292">
    <br>
    <blockquote type="cite" cite="mid:CALA8O7pVuB6ccZv8S9hs4T8OE32U76JR6Wn1xQxd-SrnqLySSQ@mail.gmail.com">
    <p dir="ltr">Maintenant tu parles de virtual host, ce qui implique
    Apache..</p>
    <p dir="ltr">Il faut éclaircir cela. Comment est appelé ton script
    ? Via une page web ?</p>
    </blockquote>
    Oui depuis le navigateur.<br>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bernard Bass@21:1/5 to All on Wed Oct 2 20:20:01 2024
    This is a multi-part message in MIME format.
    Mais qui execute l'interpréteur ? Avec chmod 000 seul root peut
    accéder au fichier. (Sauf bit sticky, que j'ai toujours un léger mal à assimiler)

    Comme quoi que non c'est étrange !
    Le fichier test.php echo Bonjour depuis le navigateur, pour un fichier a
    chmod 000 et donné a un utilisateur lambda, qui n'est pas configuré dans
    la configuration fpm pool.d.
    C'est vraiment bizzard.
    <!DOCTYPE html>
    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body text="#000000" bgcolor="#929292">
    <br>
    <blockquote type="cite" cite="mid:CALA8O7o-vByS4Eqzp8XHndtTc6xcmvW_FxKc=DYmrVSJ0=vmkQ@mail.gmail.com">
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <p dir="ltr">Mais qui execute l'interpréteur ? Avec chmod 000 seul
    root peut accéder au fichier. (Sauf bit sticky, que j'ai
    toujours un léger mal à assimiler)</p>
    </blockquote>
    Comme quoi que non c'est étrange !<br>
    Le fichier test.php echo Bonjour depuis le navigateur, pour un
    fichier a chmod 000 et donné a un utilisateur lambda, qui n'est pas
    configuré dans la configuration fpm pool.d.<br>
    C'est vraiment bizzard.<br>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bernard Bass@21:1/5 to All on Wed Oct 2 21:20:01 2024
    This is a multi-part message in MIME format.
    Ah, tu utilises PHP fpm. Il me semble qu'on spécifier un user distinct d'apache. Il faut vérifier car je ne vais pas souvent jouer avec la
    config de PHP fpm.

    En tout cas je ne vois toujours pas ce que sudo a à voir avec ton
    problème. Il faut que tu explique cette partie là. Peut être que c'est
    un aspect inutile ?

    Oui c'est un aspect inutile car je n'est pas donné de droits
    supplémentaires à ce sudoer.
    ( Par exemple exécuter des services sans donner le mot de passe sudo ... )

    J'ai testé en donnant le fichier test.php a un autre utilisateur sudoer
    qui n'a que le droit de lire les logs du groupe adm. (lirelog)
    Pareil, le fichier test.php en chmod 400 appartenant à lirelog:lirelog
    est interprété et affiche bonjour.
    <!DOCTYPE html>
    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body text="#000000" bgcolor="#929292">
    <blockquote type="cite" cite="mid:CALA8O7pRfyhBzG0QKe8Z0m9_ydR6w3i2CTbonEqARMc0n0mpFA@mail.gmail.com">
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <p dir="ltr">Ah, tu utilises PHP fpm. Il me semble qu'on spécifier
    un user distinct d'apache. Il faut vérifier car je ne vais pas
    souvent jouer avec la config de PHP fpm. </p>
    <p dir="ltr">En tout cas je ne vois toujours pas ce que sudo a à
    voir avec ton problème. Il faut que tu explique cette partie là.
    Peut être que c'est un aspect inutile ?</p>
    </blockquote>
    Oui c'est un aspect inutile car je n'est pas donné de droits
    supplémentaires à ce sudoer.<br>
    ( Par exemple exécuter des services sans donner le mot de passe sudo
    ... )<br>
    <br>
    J'ai testé en donnant le fichier test.php a un autre utilisateur
    sudoer qui n'a que le droit de lire les logs du groupe adm.
    (lirelog)<br>
    Pareil, le fichier test.php en chmod 400 appartenant à
    lirelog:lirelog est interprété et affiche bonjour.<br>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From ajh-valmer@21:1/5 to All on Wed Oct 2 23:00:01 2024
    On Wednesday 02 October 2024 20:00:46 Bernard Bass wrote:
    Mes fichiers Web .php se trouvent sous le répertoire html :
    -rw-rw-r-- propriétaire 33 , groupe 1004.

    Normalement, on les met dans le répertoire /var/www/
    user : www-data groupe : www-data
    dans ce mode : -rw- rw- r--
    Groupe 1004 c'est qui ? Apache ?

    Normalement oui,
    c'est notre admin-sys qui a réinstallé notre Debian en mode Docker, (containers).
    Je ne sais ce qu'est le groupe 1004, ainsi que le user 33.
    On peut installer les fichiers du site dans n'importe quel répertoire,
    suffit de le déclarer dans un fichier de config d'Apache.

    J'ai remis le chmod 400 sur le fichier.
    C'est fou que avec un chmod 000 le fichier soit lisible de l'extérieur... Tout comme je pensais vraiment qu'un utilisateur lambda ne pouvait pas executer le fichier.php.
    Si je configure php fpm depuis un fichier de conf dans pool.d pour dire
    à PHP d'utiliser utilisateurphp,
    Alors peut être que utilisateur lamdba ne pourra plus interpréter le
    echo bonjour.

    On peut mettre les fichiers en chmod 400, mais pour les modifier
    ça peut être refusé.
    Pour installer PHP, il faut installer Apache, ça va de pair.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?S=C3=A9bastien_NOBILI?=@21:1/5 to All on Thu Oct 3 08:50:01 2024
    Bonjour,

    Le 2024-10-02 17:26, Bernard Bass a écrit :
    J'ai voulu "protéger" un fichier.php en le donnant à mon utilisateur sudoer, que j'utilise pour administrer la machine.
    Sans élévation de droit, il s'agit d'un simple utilisateur lambda.

    Quelle est la finalité de tout ça ?

    Ce qui se pratique habituellement c'est de créer un vhost par site/appli
    avec la racine
    ("DocumentRoot" pour Apache, "root" pour Nginx) correctement
    positionnée.

    Le serveur Web se chargera de n'exposer que ce qui se trouve dans le
    dossier racine.

    Si on veut être un peu plus robuste, on peut créer un PHP FPM dédié par site/appli.

    Si on veut être encore plus robuste, on peut créer un conteneur (Docker,
    LXC, autre)
    par site/appli.

    On peut aussi créer un serveur par site/appli, mais là ça devient
    vraiment lourd pour
    pas grand-chose.

    Si un script est dangereux et ne devrait pas être exploitable à
    distance, alors il faut
    le sortir de la racine ou ajouter une directive spécifique pour que le
    serveur Web refuse
    de servir les requêtes qui arrivent dessus.

    Sébastien

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bernard Bass@21:1/5 to All on Thu Oct 3 13:50:01 2024
    This is a multi-part message in MIME format.
    J'ai voulu "protéger" un fichier.php en le donnant à mon utilisateur
    sudoer, que j'utilise pour administrer la machine.
    Sans élévation de droit, il s'agit d'un simple utilisateur lambda.

    Quelle est la finalité de tout ça ?

    Faire en sorte qu'un utilisateur lambda ne puisse pas interpréter php ?

    Ce qui se pratique habituellement c'est de créer un vhost par
    site/appli avec la racine
    ("DocumentRoot" pour Apache, "root" pour Nginx) correctement positionnée.

    C'est le cas.

    Le serveur Web se chargera de n'exposer que ce qui se trouve dans le
    dossier racine.


    Oui.

    Si on veut être un peu plus robuste, on peut créer un PHP FPM dédié
    par site/appli.


    C'est fait ou en cours d'être fait. Oui.


    Si on veut être encore plus robuste, on peut créer un conteneur
    (Docker, LXC, autre)
    par site/appli.


    Totalement surchargé avec cela, trop de besoins d'apprentissage sur l'ensemble, je ne sais gérer Docker et encore moins LXC.


    On peut aussi créer un serveur par site/appli, mais là ça devient
    vraiment lourd pour
    pas grand-chose.

    Tout à fait, de 20 ans d'apprentissage nous passons à 35 ans
    d'apprentissage pour arriver à la conclusion que nous sommes dépassés.

    Si un script est dangereux et ne devrait pas être exploitable à
    distance, alors il faut
    le sortir de la racine ou ajouter une directive spécifique pour que le serveur Web refuse
    de servir les requêtes qui arrivent dessus.


    Oui cela semble logique :)
    Un outil dangereux, on ne le conserve pas !


    Mais au final, mon petit echo bonjour fonctionne toujours avec
    l'utilisateur lambda ;)
    En attente de tester avec un user configuré depuis pool.d

    Si d'autres personnes ont des avis sur ce problème, qu'un utilisateur
    lambda du serveur puisse interpréter PHP, dans /var/www/ cela me semble étonnant, ou alors, je redécouvre que je n'ai rien compris à l'interprétation de PHP par les utilisateurs de la machine.

    On arrête jamais d'oublier qu'on savait qu'on a oublié qu'un jour on a
    appris qu'on a su et qu'on a oublié ...

    <!DOCTYPE html>
    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body text="#000000" bgcolor="#929292">
    <br>
    <blockquote type="cite" cite="mid:d09e54bf5d2cd22afa36e410a5582cfe@roundcube.pipoprods.org">
    <blockquote type="cite">J'ai voulu "protéger" un fichier.php en le
    donnant à mon utilisateur sudoer, que j'utilise pour administrer
    la machine.
    <br>
    Sans élévation de droit, il s'agit d'un simple utilisateur
    lambda.
    <br>
    </blockquote>
    <br>
    Quelle est la finalité de tout ça ?
    <br>
    </blockquote>
    <br>
    Faire en sorte qu'un utilisateur lambda ne puisse pas interpréter
    php ?<br>
    <br>
    <blockquote type="cite" cite="mid:d09e54bf5d2cd22afa36e410a5582cfe@roundcube.pipoprods.org">
    Ce qui se pratique habituellement c'est de créer un vhost par
    site/appli avec la racine
    <br>
    ("DocumentRoot" pour Apache, "root" pour Nginx) correctement
    positionnée.
    <br>
    </blockquote>
    <br>
    C'est le cas.<br>
    <br>
    <blockquote type="cite" cite="mid:d09e54bf5d2cd22afa36e410a5582cfe@roundcube.pipoprods.org">
    Le serveur Web se chargera de n'exposer que ce qui se trouve dans
    le dossier racine.
    <br>
    </blockquote>
    <p><br>
    Oui.<br>
    <br>
    </p>
    <blockquote type="cite" cite="mid:d09e54bf5d2cd22afa36e410a5582cfe@roundcube.pipoprods.org">
    Si on veut être un peu plus robuste, on peut créer un PHP FPM
    dédié par site/appli.<br>
    </blockquote>
    <p><br>
    C'est fait ou en cours d'être fait. Oui.<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite" cite="mid:d09e54bf5d2cd22afa36e410a5582cfe@roundcube.pipoprods.org">
    Si on veut être encore plus robuste, on peut créer un conteneur
    (Docker, LXC, autre)
    <br>
    par site/appli.<br>
    </blockquote>
    <p><br>
    Totalement surchargé avec cela, trop de besoins d'apprentissage
    sur l'ensemble, je ne sais gérer Docker et encore moins LXC.<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite" cite="mid:d09e54bf5d2cd22afa36e410a5582cfe@roundcube.pipoprods.org">
    On peut aussi créer un serveur par site/appli, mais là ça devient
    vraiment lourd pour
    <br>
    pas grand-chose.<br>
    </blockquote>
    <br>
    Tout à fait, de 20 ans d'apprentissage nous passons à 35 ans
    d'apprentissage pour arriver à la conclusion que nous sommes
    dépassés.<br>
    <br>
    <blockquote type="cite" cite="mid:d09e54bf5d2cd22afa36e410a5582cfe@roundcube.pipoprods.org">
    Si un script est dangereux et ne devrait pas être exploitable à
    distance, alors il faut
    <br>
    le sortir de la racine ou ajouter une directive spécifique pour
    que le serveur Web refuse
    <br>
    de servir les requêtes qui arrivent dessus.
    <br>
    </blockquote>
    <p><br>
    Oui cela semble logique :)<br>
    Un outil dangereux, on ne le conserve pas !<br>
    </p>
    <p><br>
    Mais au final, mon petit echo bonjour fonctionne toujours avec
    l'utilisateur lambda ;)<br>
    En attente de tester avec un user configuré depuis pool.d<br>
    <br>
    Si d'autres personnes ont des avis sur ce problème, qu'un
    utilisateur lambda du serveur puisse interpréter PHP, dans
    /var/www/ cela me semble étonnant, ou alors, je redécouvre que je
    n'ai rien compris à l'interprétation de PHP par les utilisateurs
    de la machine.<br>
    <br>
    On arrête jamais d'oublier qu'on savait qu'on a oublié qu'un jour
    on a appris qu'on a su et qu'on a oublié ...<br>
    </p>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?S=C3=A9bastien_NOBILI?=@21:1/5 to All on Thu Oct 3 14:10:01 2024
    Le 2024-10-03 13:25, Bernard Bass a écrit :
    Faire en sorte qu'un utilisateur lambda ne puisse pas interpréter php ?

    Pourquoi ?

    Si d'autres personnes ont des avis sur ce problème, qu'un utilisateur
    lambda du serveur puisse interpréter PHP, dans /var/www/ cela me semble étonnant, ou alors, je redécouvre que je n'ai rien compris à l'interprétation de PHP par les utilisateurs de la machine.

    Il n'y a aucune raison à ça :

    ```
    $ ls -l /usr/bin/php8.2
    -rwxr-xr-x 1 root root 5,4M 27 sept. 06:16 /usr/bin/php8.2*
    ```

    Tout le monde peux exécuter l'interpréteur PHP. Et c'est assez logique : interpréter du PHP n'a
    rien de dangereux en soi, aucune raison de le limiter.

    Sébastien

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eric DEGENETAIS@21:1/5 to All on Thu Oct 3 15:00:01 2024

    Tout le monde peux exécuter l'interpréteur PHP. Et c'est assez logique : interpréter du PHP n'a
    rien de dangereux en soi, aucune raison de le limiter.


    À mes yeux, il y a deux choses à gérer :
    1 - s'assurer que l'utilisateur qui fait l'exécution php n'ait que les privilèges nécessaires (les droits du fichiers n'interviennent pas à
    ce stade, sauf qu'il doit être lisible par le moteur php).
    2 - limiter la possibilité que le script soit modifié pour faire autre
    chose que prévu => l'utilisateur du vhost n'a que le droit de le lire,
    le droit d'écriture étant réservé à un autre compte utilisé pour faire les mises à jour. C'est sur ce dernier point que les droits du fichier
    sont pertinents. Et par principe, je ne le rendrais pas exécutable,
    puisqu'il ne sera pas exécuté au sens système, maïs interprété par le moteur php (qui - lui - doit être exécutable pour le compte de service concerné).

    Sébastien

    Eric

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bernard Bass@21:1/5 to All on Fri Oct 4 05:50:01 2024
    This is a multi-part message in MIME format.
    Le 03/10/2024 à 14:56, Eric DEGENETAIS a écrit :
    1 - s'assurer que l'utilisateur qui fait l'exécution php n'ait que les privilèges nécessaires (les droits du fichiers n'interviennent pas à
    ce stade, sauf qu'il doit être lisible par le moteur php).
    2 - limiter la possibilité que le script soit modifié pour faire autre chose que prévu => l'utilisateur du vhost n'a que le droit de le lire,
    le droit d'écriture étant réservé à un autre compte utilisé pour faire les mises à jour. C'est sur ce dernier point que les droits du fichier
    sont pertinents. Et par principe, je ne le rendrais pas exécutable, puisqu'il ne sera pas exécuté au sens système, maïs interprété par le moteur php (qui - lui - doit être exécutable pour le compte de service concerné).
    Cela est OK.
    Merci.
    <!DOCTYPE html>
    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body text="#000000" bgcolor="#929292">
    <p><br>
    </p>
    <div class="moz-cite-prefix">Le 03/10/2024 à 14:56, Eric DEGENETAIS
    a écrit :<br>
    </div>
    <blockquote type="cite" cite="mid:CAHZRFdmGjK7aNCLqMvzs+cTU=t6=o-UzPweYYAgEzGYytftOwQ@mail.gmail.com">
    <pre>1 - s'assurer que l'utilisateur qui fait l'exécution php n'ait que les
    privilèges nécessaires (les droits du fichiers n'interviennent pas à
    ce stade, sauf qu'il doit être lisible par le moteur php).
    2 - limiter la possibilité que le script soit modifié pour faire autre
    chose que prévu =&gt; l'utilisateur du vhost n'a que le droit de le lire,
    le droit d'écriture étant réservé à un autre compte utilisé pour faire les mises à jour. C'est sur ce dernier point que les droits du fichier
    sont pertinents. Et par principe, je ne le rendrais pas exécutable,
    puisqu'il ne sera pas exécuté au sens système, maïs interprété par le moteur php (qui - lui - doit être exécutable pour le compte de service concerné).</pre>
    </blockquote>
    Cela est OK.<br>
    Merci.<br>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michel Verdier@21:1/5 to All on Fri Oct 4 11:00:01 2024
    Le 3 octobre 2024 Eric DEGENETAIS a écrit :

    2 - limiter la possibilité que le script soit modifié pour faire autre chose que prévu => l'utilisateur du vhost n'a que le droit de le lire,
    le droit d'écriture étant réservé à un autre compte utilisé pour faire les mises à jour. C'est sur ce dernier point que les droits du fichier
    sont pertinents. Et par principe, je ne le rendrais pas exécutable, puisqu'il ne sera pas exécuté au sens système, maïs interprété par le moteur php (qui - lui - doit être exécutable pour le compte de service concerné).

    Pour compléter ça je dirais qu'une première étape est d'utiliser phpinfo plutôt qu'un "hello world"
    https://www.php.net/manual/fr/function.phpinfo.php

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Erwann Le Bras@21:1/5 to All on Sun Oct 6 15:50:01 2024
    This is a multi-part message in MIME format.
    Bonjour

    On est pas en train de tout mélanger?

    Si j'ai bien  compris s'agit de protéger en exécution un script PHP
    lancé depuis un navigateur

    Donc ici pas de notion d'utilisateur ni de sudo car tout repose sur le
    serveur web qui  va déterminer qui a le droit ou non selon la
    configuration :

    * IP source
    * Authentification et mot de passe

    amitiés

    Erwann

    Le 03/10/2024 à 13:25, Bernard Bass a écrit :

    J'ai voulu "protéger" un fichier.php en le donnant à mon utilisateur
    sudoer, que j'utilise pour administrer la machine.
    Sans élévation de droit, il s'agit d'un simple utilisateur lambda.

    Quelle est la finalité de tout ça ?

    Faire en sorte qu'un utilisateur lambda ne puisse pas interpréter php ?

    Ce qui se pratique habituellement c'est de créer un vhost par
    site/appli avec la racine
    ("DocumentRoot" pour Apache, "root" pour Nginx) correctement
    positionnée.

    C'est le cas.

    Le serveur Web se chargera de n'exposer que ce qui se trouve dans le
    dossier racine.


    Oui.

    Si on veut être un peu plus robuste, on peut créer un PHP FPM dédié
    par site/appli.


    C'est fait ou en cours d'être fait. Oui.


    Si on veut être encore plus robuste, on peut créer un conteneur
    (Docker, LXC, autre)
    par site/appli.


    Totalement surchargé avec cela, trop de besoins d'apprentissage sur l'ensemble, je ne sais gérer Docker et encore moins LXC.


    On peut aussi créer un serveur par site/appli, mais là ça devient
    vraiment lourd pour
    pas grand-chose.

    Tout à fait, de 20 ans d'apprentissage nous passons à 35 ans d'apprentissage pour arriver à la conclusion que nous sommes dépassés.

    Si un script est dangereux et ne devrait pas être exploitable à
    distance, alors il faut
    le sortir de la racine ou ajouter une directive spécifique pour que
    le serveur Web refuse
    de servir les requêtes qui arrivent dessus.


    Oui cela semble logique :)
    Un outil dangereux, on ne le conserve pas !


    Mais au final, mon petit echo bonjour fonctionne toujours avec
    l'utilisateur lambda ;)
    En attente de tester avec un user configuré depuis pool.d

    Si d'autres personnes ont des avis sur ce problème, qu'un utilisateur lambda du serveur puisse interpréter PHP, dans /var/www/ cela me
    semble étonnant, ou alors, je redécouvre que je n'ai rien compris à l'interprétation de PHP par les utilisateurs de la machine.

    On arrête jamais d'oublier qu'on savait qu'on a oublié qu'un jour on a appris qu'on a su et qu'on a oublié ...

    <!DOCTYPE html>
    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body>
    <p>Bonjour</p>
    <p>On est pas en train de tout mélanger?</p>
    <p>Si j'ai bien  compris s'agit de protéger en exécution un script
    PHP lancé depuis un navigateur</p>
    <p>Donc ici pas de notion d'utilisateur ni de sudo car tout repose
    sur le serveur web qui  va déterminer qui a le droit ou non selon
    la configuration :</p>
    <ul>
    <li>IP source<br>
    </li>
    <li>Authentification et mot de passe</li>
    </ul>
    <p>amitiés</p>
    <p>Erwann<br>
    </p>
    <div class="moz-cite-prefix">Le 03/10/2024 à 13:25, Bernard Bass a
    écrit :<br>
    </div>
    <blockquote type="cite"
    cite="mid:856f4b5a-1526-4872-927a-aa9ccbc87da6@visionduweb.com">
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <br>
    <blockquote type="cite" cite="mid:d09e54bf5d2cd22afa36e410a5582cfe@roundcube.pipoprods.org">
    <blockquote type="cite">J'ai voulu "protéger" un fichier.php en
    le donnant à mon utilisateur sudoer, que j'utilise pour
    administrer la machine. <br>
    Sans élévation de droit, il s'agit d'un simple utilisateur
    lambda. <br>
    </blockquote>
    <br>
    Quelle est la finalité de tout ça ? <br>
    </blockquote>
    <br>
    Faire en sorte qu'un utilisateur lambda ne puisse pas interpréter
    php ?<br>
    <br>
    <blockquote type="cite" cite="mid:d09e54bf5d2cd22afa36e410a5582cfe@roundcube.pipoprods.org"> Ce
    qui se pratique habituellement c'est de créer un vhost par
    site/appli avec la racine <br>
    ("DocumentRoot" pour Apache, "root" pour Nginx) correctement
    positionnée. <br>
    </blockquote>
    <br>
    C'est le cas.<br>
    <br>
    <blockquote type="cite" cite="mid:d09e54bf5d2cd22afa36e410a5582cfe@roundcube.pipoprods.org"> Le
    serveur Web se chargera de n'exposer que ce qui se trouve dans
    le dossier racine. <br>
    </blockquote>
    <p><br>
    Oui.<br>
    <br>
    </p>
    <blockquote type="cite" cite="mid:d09e54bf5d2cd22afa36e410a5582cfe@roundcube.pipoprods.org"> Si
    on veut être un peu plus robuste, on peut créer un PHP FPM dédié
    par site/appli.<br>
    </blockquote>
    <p><br>
    C'est fait ou en cours d'être fait. Oui.<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite" cite="mid:d09e54bf5d2cd22afa36e410a5582cfe@roundcube.pipoprods.org"> Si
    on veut être encore plus robuste, on peut créer un conteneur
    (Docker, LXC, autre) <br>
    par site/appli.<br>
    </blockquote>
    <p><br>
    Totalement surchargé avec cela, trop de besoins d'apprentissage
    sur l'ensemble, je ne sais gérer Docker et encore moins LXC.<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite" cite="mid:d09e54bf5d2cd22afa36e410a5582cfe@roundcube.pipoprods.org"> On
    peut aussi créer un serveur par site/appli, mais là ça devient
    vraiment lourd pour <br>
    pas grand-chose.<br>
    </blockquote>
    <br>
    Tout à fait, de 20 ans d'apprentissage nous passons à 35 ans
    d'apprentissage pour arriver à la conclusion que nous sommes
    dépassés.<br>
    <br>
    <blockquote type="cite" cite="mid:d09e54bf5d2cd22afa36e410a5582cfe@roundcube.pipoprods.org"> Si
    un script est dangereux et ne devrait pas être exploitable à
    distance, alors il faut <br>
    le sortir de la racine ou ajouter une directive spécifique pour
    que le serveur Web refuse <br>
    de servir les requêtes qui arrivent dessus. <br>
    </blockquote>
    <p><br>
    Oui cela semble logique :)<br>
    Un outil dangereux, on ne le conserve pas !<br>
    </p>
    <p><br>
    Mais au final, mon petit echo bonjour fonctionne toujours avec
    l'utilisateur lambda ;)<br>
    En attente de tester avec un user configuré depuis pool.d<br>
    <br>
    Si d'autres personnes ont des avis sur ce problème, qu'un
    utilisateur lambda du serveur puisse interpréter PHP, dans
    /var/www/ cela me semble étonnant, ou alors, je redécouvre que
    je n'ai rien compris à l'interprétation de PHP par les
    utilisateurs de la machine.<br>
    <br>
    On arrête jamais d'oublier qu'on savait qu'on a oublié qu'un
    jour on a appris qu'on a su et qu'on a oublié ...<br>
    </p>
    </blockquote>
    <div id="grammalecte_menu_main_button_shadow_host"
    style="width: 0px; height: 0px;"></div>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bernard Bass@21:1/5 to All on Thu Nov 7 18:30:01 2024
    This is a multi-part message in MIME format.
    J'ai voulu "protéger" un fichier.php en le donnant à mon utilisateur sudoer, que j'utilise pour administrer la machine.
    Sans élévation de droit, il s'agit d'un simple utilisateur lambda.

    Je suis étonné de voir que le fichier.php est tout de même interprété. Est-ce normal ?


    Je conclu avec un chmod 000.


    Utiliser CHMOD pour refuser au serveur Apache le droit de lire
    un fichier PHP

    ######################################################################################################################
    # Comment interdire à Apache 2.4 d'interpréter un fichier ip.php ? #
    # Interdire l'interprétation du fichier ip.php par l'utilisateur www-data configuré pour apache2. #
    # Interdire l'interprétation du fichier ip.php par l'utilisateur UTILISATEUR-DU-POOL-PHP-FPM configuré pour apache2. #
    ######################################################################################################################

    # Les permissions sur les fichiers et les dossiers se définissent avec CHMOD. # La commande chmod permet de modifier les permissions du propriétaire d'un fichier.
    # La commande setfacl pour gérer les ACL ne permet en aucun cas de modifier les permissions propriétaires pour un fichier ou un dossier !

    # Sachant que les ACL ne peuvent pas modifier les droits du propriétaire.
    # Sachant que www-data est propriétaire des fichiers apache en temps normal.
    # Sachant que www-data-fpm est le propriétaire des fichiers configuré dans la configuration de php-fpm du répertoire pool.d.

    # Si www-data ou www-data-fpm sont propriétaires des fichiers, les ACL ne pourront pas leur retirer les permissions de lecture, écriture ou exécution.
    # Utiliser la commande setfacl pour interdire l'interprétation du fichier ip.php ne fonctionnera pas sur les droits du propriétaire des fichiers.
    # Les permissions du propriétaire restent prioritaires, même si les ACL sont configurées pour restreindre d'autres utilisateurs ou groupes.

    # Les droits CHMOD 644 sont appliqués sur le fichier "ip.php" qui est donc lisible de tout le monde depuis le navigateur :
    chmod 644 ip.php
    ls -la ip.php
    -rw-r--r-- 1 www-data www-data ip.php

    # On vérifier si des droits ACL existent sur le fichier "ip.php" avec la commande getfacl.
    # Aucune ACL n'est présente par défaut sur le fichier "ip.php" :
    getfacl ip.php
    # file: ip.php
    # owner: www-data
    # group: www-data
    user::rw-
    group::r--
    other::r--

    # Pour empêcher l'interprétation du fichier ip.php il faut enlever la permission de lecture au propriétaire du fichier avec CHMOD.
    # Utiliser la commande chmod sur le fichier ip.php pour enlever la permission de lecture au propriétaire :
    # (user::r--)(www-data) :
    chmod u-r ip.php

    # Attention !
    # Il faut toujours redémarrer le service apache2 et php8.2-fpm après avoir utilisé CHMOD pour appliquer le changement de droits CHMOD :
    sudo systemctl restart apache2
    sudo systemctl restart php8.2-fpm

    # Sans le droit propriétaire de lecture sur le fichier ip.php, le fichier ip.php n'est pas interprété par Apache2 depuis le navigateur !
    # Le navigateur affiche le message suivant :
    Access denied.

    # Attention :
    # Les autres droits CHMOD sont toujours présents :
    ls -la ip.php
    --w-r--r--

    # Un simple utilisateur Linux pourra toujours afficher le résultat du fichier ip.php depuis le terminal :
    # Le fichier ip.php est interprété et affiché par apache 2.4 :
    php ip.php

    # Utiliser la commande CHMOD sur le fichier ip.php pour enlever toutes les permissions ce qui va empêcher Apache 2.4 de lire le fichier et donc de l'interpréter :
    chmod 000 ip.php

    # Attention :
    # Il faut toujours redémarrer le service apache2 et php8.2-fpm après avoir utilisé CHMOD pour appliquer le changement de droits CHMOD :
    sudo systemctl restart apache2
    sudo systemctl restart php8.2-fpm

    # Avec un CHMOD 000 il n'y a aucun droit sur le fichier ip.php, le fichier ip.php n'est pas interprété par Apache2 depuis le navigateur !
    # Le navigateur affiche le message suivant :
    Access denied.

    # Le message affiché dans le error.log de Apache2 confirme que le CHMOD 000 a permis d'interdire l'interprétation du fichier ip.php depuis le navigateur :
    AH01071: Got error 'PHP message: PHP Warning: PHP Request Startup: Failed to open stream: Permission denied in Unknown on line 0;
    Unable to open primary script: //var/www/joomla/ip.php (Permission denied)'

    # Sans aucun droit d'accès sur le fichier ip.php, le fichier ip.php ne peut plus être interprété par Apache2 depuis le terminal !
    # Aucun message n'apparait dans les logs de PHP cli puisque les droits CHMOD 000 refuse la lecture du fichier, il n'est donc pas possible de l'interpréter !
    # Aucun utilisateur Linux ne pourra plus afficher le fichier depuis le terminal.
    php ip.php
    Could not open input file: ip.php

    # Les deux messages sont équivalents et indiquent le même problème de permissions :
    # Apache réussit à capturer l'erreur de permissions grâce à ses mécanismes intégrés :
    AH01071: Got error 'PHP message: PHP Warning: PHP Request Startup: Failed to open stream: Permission denied in Unknown on line 0;
    Unable to open primary script: //var/www/joomla/ip.php (Permission denied)'

    # PHP cli retourne le message que le fichier ne peut pas être ouvert :
    Could not open input file: ip.php

    # Que ce soit depuis Apache ou PHP CLI, les permissions chmod 000 bloquent tout accès et interprétation du fichier ip.php.
    # Utiliser la commande php cli en tant que root sur le fichier ip.php permet toujours de l'interpréter.

    #####################################################################################################
    # Interdire à Apache 2.4 d'interpréter un fichier ip.php avec un CHMOD 000 sur le fichier "ip.php". #
    # Redémarrer apache2 et php8.2-fpm pour appliquer le changement de CHMOD. #
    #####################################################################################################

    <!DOCTYPE html>
    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body text="#000000" bgcolor="#929292">
    <blockquote type="cite"
    cite="mid:c8e29647-57bc-4d36-aec5-c9e2d10c25ed@visionduweb.com">J'ai
    voulu "protéger" un fichier.php en le donnant à mon utilisateur
    sudoer, que j'utilise pour administrer la machine.<br>
    Sans élévation de droit, il s'agit d'un simple utilisateur lambda.
    <p> Je suis étonné de voir que le fichier.php est tout de même
    interprété.<br>
    Est-ce normal ?<br>
    </p>
    </blockquote>
    <p><br>
    Je conclu avec un chmod 000.<br>
    </p>
    <h5><span class="mw-headline" id="Utiliser_CHMOD_pour_refuser_au_serveur_Apache_le_droit_de_lire_un_fichier_PHP">Utiliser
    CHMOD pour refuser au serveur Apache le droit de lire un fichier
    PHP</span></h5>
    <pre>######################################################################################################################
    # Comment interdire à Apache 2.4 d'interpréter un fichier ip.php ? #
    # Interdire l'interprétation du fichier ip.php par l'utilisateur www-data configuré pour apache2. #
    # Interdire l'interprétation du fichier ip.php par l'utilisateur UTILISATEUR-DU-POOL-PHP-FPM configuré pour apache2. #
    ######################################################################################################################
    </pre>
    <pre># Les permissions sur les fichiers et les dossiers se définissent avec CHMOD.
    # La commande chmod permet de modifier les permissions du propriétaire d'un fichier.
    # La commande setfacl pour gérer les ACL ne permet en aucun cas de modifier les permissions propriétaires pour un fichier ou un dossier !
    </pre>
    <pre># Sachant que les ACL ne peuvent pas modifier les droits du propriétaire.
    # Sachant que www-data est propriétaire des fichiers apache en temps normal.
    # Sachant que www-data-fpm est le propriétaire des fichiers configuré dans la configuration de php-fpm du répertoire pool.d.
    </pre>
    <pre># Si www-data ou www-data-fpm sont propriétaires des fichiers, les ACL ne pourront pas leur retirer les permissions de lecture, écriture ou exécution.
    # Utiliser la commande setfacl pour interdire l'interprétation du fichier ip.php ne fonctionnera pas sur les droits du propriétaire des fichiers.
    # Les permissions du propriétaire restent prioritaires, même si les ACL sont configurées pour restreindre d'autres utilisateurs ou groupes.
    </pre>
    <pre># Les droits CHMOD 644 sont appliqués sur le fichier "ip.php" qui est donc lisible de tout le monde depuis le navigateur :
    chmod 644 ip.php
    ls -la ip.php
    -rw-r--r-- 1 www-data www-data ip.php
    </pre>
    <pre># On vérifier si des droits ACL existent sur le fichier "ip.php" avec la commande getfacl.
    # Aucune ACL n'est présente par défaut sur le fichier "ip.php" :
    getfacl ip.php
    # file: ip.php
    # owner: www-data
    # group: www-data
    user::rw-
    group::r--
    other::r--
    </pre>
    <pre># Pour empêcher l'interprétation du fichier ip.php il faut enlever la permission de lecture au propriétaire du fichier avec CHMOD.
    # Utiliser la commande chmod sur le fichier ip.php pour enlever la permission de lecture au propriétaire :
    # (user::r--)(www-data) :
    chmod u-r ip.php
    </pre>
    <pre># Attention !
    # Il faut toujours redémarrer le service apache2 et php8.2-fpm après avoir utilisé CHMOD pour appliquer le changement de droits CHMOD :
    sudo systemctl restart apache2
    sudo systemctl restart php8.2-fpm
    </pre>
    <pre># Sans le droit propriétaire de lecture sur le fichier ip.php, le fichier ip.php n'est pas interprété par Apache2 depuis le navigateur !
    # Le navigateur affiche le message suivant :
    Access denied.
    </pre>
    <pre># Attention :
    # Les autres droits CHMOD sont toujours présents :
    ls -la ip.php
    --w-r--r--
    </pre>
    <pre># Un simple utilisateur Linux pourra toujours afficher le résultat du fichier ip.php depuis le terminal :
    # Le fichier ip.php est interprété et affiché par apache 2.4 :
    php ip.php
    </pre>
    <pre># Utiliser la commande CHMOD sur le fichier ip.php pour enlever toutes les permissions ce qui va empêcher Apache 2.4 de lire le fichier et donc de l'interpréter :
    chmod 000 ip.php
    </pre>
    <pre># Attention :
    # Il faut toujours redémarrer le service apache2 et php8.2-fpm après avoir utilisé CHMOD pour appliquer le changement de droits CHMOD :
    sudo systemctl restart apache2
    sudo systemctl restart php8.2-fpm
    </pre>
    <pre># Avec un CHMOD 000 il n'y a aucun droit sur le fichier ip.php, le fichier ip.php n'est pas interprété par Apache2 depuis le navigateur !
    # Le navigateur affiche le message suivant :
    Access denied.
    </pre>
    <pre># Le message affiché dans le error.log de Apache2 confirme que le CHMOD 000 a permis d'interdire l'interprétation du fichier ip.php depuis le navigateur :
    AH01071: Got error 'PHP message: PHP Warning: PHP Request Startup: Failed to open stream: Permission denied in Unknown on line 0;
    Unable to open primary script: //var/www/joomla/ip.php (Permission denied)' </pre>
    <pre># Sans aucun droit d'accès sur le fichier ip.php, le fichier ip.php ne peut plus être interprété par Apache2 depuis le terminal !
    # Aucun message n'apparait dans les logs de PHP cli puisque les droits CHMOD 000 refuse la lecture du fichier, il n'est donc pas possible de l'interpréter !
    # Aucun utilisateur Linux ne pourra plus afficher le fichier depuis le terminal.
    php ip.php
    Could not open input file: ip.php
    </pre>
    <pre># Les deux messages sont équivalents et indiquent le même problème de permissions :
    # Apache réussit à capturer l'erreur de permissions grâce à ses mécanismes intégrés :
    AH01071: Got error 'PHP message: PHP Warning: PHP Request Startup: Failed to open stream: Permission denied in Unknown on line 0;
    Unable to open primary script: //var/www/joomla/ip.php (Permission denied)'

    # PHP cli retourne le message que le fichier ne peut pas être ouvert :
    Could not open input file: ip.php
    </pre>
    <pre># Que ce soit depuis Apache ou PHP CLI, les permissions chmod 000 bloquent tout accès et interprétation du fichier ip.php.
    # Utiliser la commande php cli en tant que root sur le fichier ip.php permet toujours de l'interpréter.
    </pre>
    <pre>#####################################################################################################
    # Interdire à Apache 2.4 d'interpréter un fichier ip.php avec un CHMOD 000 sur le fichier "ip.php". #
    # Redémarrer apache2 et php8.2-fpm pour appliquer le changement de CHMOD. #
    #####################################################################################################
    </pre>
    <p></p>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)