Forum Programmation.web Droits serveur PHP

Posté par  .
Étiquettes : aucune
0
23
oct.
2012

Bonjour,

J'ai besoin de faire intéragir une page PHP avec un programme C sur Linux Debian,

Notamment envoyer des signaux du PHP vers le programme C.

Donc mon programme C enregistre son N° PID dans /var/run/prog.pid

Le serveur PHP lit ce PID et lance le signal SIGUSR1 :

$fp = fopen("/var/run/prog.pid", "r");
fscanf ($fp, "%d", &$pid_prog);

$ret = posix_kill($pid_prog, 10); /* SIGUSR1 */

error_log("posix_kill $pid_prog, 10 : ret = $ret");

Mais comme mon programme est lancé avec l'utilisateur "root" et le serveur PHP avec l'utilisateur "www-data", l'appel à "posix_kill" me renvoit "Operation not permitted".

L'utilisateur sous lequel est lancé PHP est défini dans /etc/apache2/envvars

Mais si on lance le serveur PHP en root on obtiens un message d'erreur :

"Apache has not been designed to serve pages while running as root. There are known race conditions that will allow any local user to read any file on the system. If you still desire to serve pages as root then add -DBIG_SECURITY_HOLE to the CFLAGS env variable and then rebuild the server. It is strongly suggested that you instead modify the User directive in your httpd.conf file to list a non-root user."

Je ne sais pas trop comment rêgler le problème

Est-il possible de permettre à l'utilisateur "www-data" d'envoyer des signaux aux programmes d'un autre group / user ?

  • # Essai avec un utilisateur à la place de root

    Posté par  . Évalué à -1.

    J'ai essayé quelque chose qui n'a pas marché :

    Création d'un utilisateur test :
    adduser test

    Ajout de "test" dans le groupe "www-data"
    et ajout de l'utilisateur "www-data" dans le groupe "test"

    /etc/group :

    www-data:x:33:test
    test:x:1000:www-data

    Je lance mon programme avec l'utilisateur "test"

    Mais ça me fait toujours "Operation not permitted"

  • # Des autres approches

    Posté par  . Évalué à 1.

    Bonjour Ilip,

    Il n'est pas possible de lancer le programme C avec l'utilisateur "www-data"? Ça c'est la façon plus simple de résoudre ce problème.

    A encore une autre façon avec le « set-user-ID-on-execution bit ». Vous pouvez utiliser le chmod pour définir ce permis et le chown poue définir l’utilisateur effectif qui va lancer le programme.

    Par exemple :
    chmod 4554 mon_programme_c
    chown www-data mon_programme_c

    Quand le utilisateur root lancer son programme, le l’utilisateur effectif sera www-data et vous pouvez l’envoyer les signaux.

    Pensez-vous à utiliser une autre approche comme les sokets par exemple?

    Excusez-moi si j’ai écrit avec des erreurs, je ne suis pas encore un francophone, mais j’étudie le français comme langue seconde.

    Cordiallement,
    Erick Azevedo

    • [^] # Re: Des autres approches

      Posté par  . Évalué à 1.

      Bonjour,

      Mon programme doit être lancé avec d'avantages de droits que le user www-data

      Les sockets sont une solution mais c'est plus lourd à implémenter

      Il faut trouver comment autoriser le serveur PHP à envoyer des signaux à des programmes qui ne sont pas dans son groupe, ou créer un groupe supplémentaire, mais ça n'a pas l'air de marcher

      • [^] # Re: Des autres approches

        Posté par  . Évalué à 3. Dernière modification le 23 octobre 2012 à 17:40.

        Bon, voilà un truc, sur mon php j'appelle : exec('./prog'); qui est un binaire ayant le setuid (debian ne permet plus de le faire manuellement, donc c'est dans le code!),
        J'utilise donc ce programme pour lancer un binaire qui a besoin d'être root (pâr exemple, chez moi un script bash, pour lire des log systeme… mais tu peut l'adapter pour qu'il envoie un signal)

        ce petit 'prog' est en quelque sorte un proxy : tu l'execute en tant que user (donc www-data par exemple), et il execute un truc en tant que root pour toi.
        facile…

        voilà.

        #include <stdio.h>
        #include <stdlib.h>
        #include <sys/types.h>
        #include <unistd.h>
        
        // 1. compiler gcc prog.c -o prog
        // 2. changer le proprio ==> chgrp root prog
        // 3. setuid : chmod 4755 prog
        // 4. lancer ./prog
        
        int main()
        {
           setuid( 0 );
           system( "/un/truc" ); // le truc a lancer en tant que root
        
           return 0;
        }
        
        
        • [^] # Re: Des autres approches

          Posté par  (site web personnel) . Évalué à 0. Dernière modification le 24 octobre 2012 à 07:49.

          Cela me parait très très très louche ton histoire !

          Qu'en exécutant un simple programme tu puisses avoir les droits root…
          Car sinon dès que j'ai un shell user sur une machine, c'est un shell root en 10 lignes de code !
          Facile de modifier ton prog et d'ajouter la lecture de paramètres qui seraient des commandes.
          Ou même de lui faire remplacer mon uid par 0 dans /etc/passwd, et hop user = root !

          NON !

          Le système de sécurité/droit unix n'est peux être plus totalement en adéquation avec les risques engendrés par le grand ternet, d'où la naissance de selinux, mais la tu es en train de dire que c'est une passoire, voir un moulin !

          Est ce que ton user a pas déjà les droits de lire ce log que tu as utilisé pour ton test ?
          Hum, hum…

          Fuse : j'en Use et Abuse !

          • [^] # Re: Des autres approches

            Posté par  (site web personnel) . Évalué à 1.

            Ah ouais j'avais pas vu dans les commentaires du programmes : tu colle un sticky bit root sur le programme !

            O_o

            C'est pas encore interdit dans le manuel de l'administrateur çà ?

            Fuse : j'en Use et Abuse !

            • [^] # Re: Des autres approches

              Posté par  . Évalué à 2.

              C'est pas encore interdit dans le manuel de l'administrateur çà ?

              c'est un peu comme un sudo, sauf que c'est pas dans le fichier sudoers.

  • # Avec un script shell et outil qui s'appel sudo !

    Posté par  (site web personnel) . Évalué à 8.

    Salut,

    J'ai déjà fais ça !

    Un interface web en php pour les dev puissent envoyer des signaux ( USR2, USR1, HUP ) sur des proc lancé en homologation par un utilisateur système auquel ils n'ont pas accès ( faut pas pousser ). En fait mon bignou permet aussi de faire des livraisons bien ciblées en tant que root localement, et des stop / start…

    1) le site web tourne en https, avec une authentification, et lance un script shell
    "sudo /files/send_sign.sh" ou "sudo /files/make_deliver.sh" …etc..

    Ce script lancé par la page php est donc lancé en tant que www-data, et avec sudo il va avoir les droits root ! Enjoy

    2) Dans ton fichier de configuration sudo tu as une entrée qui autorise apache a lancer les fameux script shell

    www-data:monserver = /files/send_sigh.sh, /files/make_deliver.sh, /files/make_stop_start.sh

    C'est simple, cloisonné, et plutôt propre je trouve

    Fuse : j'en Use et Abuse !

  • # Re: Des autres approches

    Posté par  . Évalué à 0.

    Ok merci pour vos solutions, ça répond bien au problème

    La solution setuid(0) fonctionne, la solution sudo avec un script aussi,

    On peut aussi autoriser l'utilisateur www-data d'utiliser la commande kill avec sudo :

    apt-get install sudo

    vim /etc/sudoers.d/test :
    www-data ALL= NOPASSWD: /bin/kill

    code PHP :

    exec sudo kill -SIGTERM $pid

    Mais c'est peut être plus sécurisé de passer par un script intermédiare

    • [^] # Re: Des autres approches

      Posté par  (site web personnel) . Évalué à 3.

      L'approche que tu proposes autorises apache a tuer TOUT les process de la machine, y compris les process critique !

      Ce qui veux dire qu'en cas d'exploit donnant un shell avec user www-data sur ta machine, ben je la descend…

      Définitivement le script intermédiaire est plus <anglais> secure </anglais>

      Fuse : j'en Use et Abuse !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.