• [^] # Re: ce Maudit GRSecurity

    Posté par . En réponse au journal ce Maudit GRSecurity. Évalué à 1.

    ben ouais , je sais que c un bloquage de grSecurity (enfin je pense)
    ce qui m'embête c'est que la seule solution que j'ai trouvé C T de
    recompiler le noyau en enlevant GrSecurity et comme solution, c'est can
    même pas térible je trouve.

    Je pense qu'il existe un moyen pour "dire" à grsecurity que l'utilisateur
    apache a le droit d'executé des binaires qui ne lui appartiennent pas.

    Si j'essai en ligne de commande voilà le resultat :
    (apacheftp et apache ont le même UserID et GroupID)

    > [root@ProxyDNG root]# su - apacheftp
    > -bash-2.05b$ cd /home/sogarf/public_html/cgi-bin/
    > -bash-2.05b$ ./index.cgi
    > -bash: ./index.cgi: /bin/sh: bad interpreter: Permission denied

    et dans les log j'ai :
    > Sep 3 14:04:40 ProxyDNG kernel: grsec: denied exec of ./index.cgi by (bash:11479) UID(72) EUID(72), parent (bash:22818) UID(72) EUID(72) reason: untrusted

    Je pense vraiment que c'est un problème de sécurité qui empèche
    l'utilisateur apache d'executé un programme qui ne lui appartient pas.
    Apache est lui bien configuré étant donné que les cgi appartenant a
    apache fonctionne.

    De plus, les fichiers sont tous en 755.



    Je viens de testé un truc, le repertoire de apache est dans /home/www.
    Le repertoire de mon utilisateur est /home/sogarf.

    Si j'affecte le cgi a l'utilisateur apache:apache, ca ne fonctionne tjs pas
    Par contre, un chown apache:apache -R /home/sogarf, et hop la
    l'execution fonction, mais la solution n'est pas bonne, car le but
    est de pourvoir administrer de site de sogarf via ftp.