Bueno, ya está todo ok y funcionando perfectamente muchas gracias por el tiempo y la paciencia.

Saludos.

eaeaeaaa ahi sii pero me funciona con system() no con shell_exec(), no se porque pero ya no es mi prioridad xD

Ahora volveré a habilitar selinux como estaba y configuraré el script para que pueda ser ejecutado por apache para no afectar la seguridad nativa del sistema

El mismo mensaje de error y ya agregué /bin/bash al usuario apache desde /etc/passwd y al ejecutar su apache entra directamente al bash, pero aun así quiere funcionar en php, talves sea algo de sudoers.

Bueno, para ir descartando puse selinux en modo permisivo y reinicié la maquina, ahora ejecuto:


Ahora si efectivamente el sudoers funciona perfectamente, pero el script en php no puede ejecutar el mismo comando a pesar de que tenga el mismo permiso. El log de errores dice:


Será que debo asignarle un bash al usuario apache dentro del /etc/passwd?

Pues si, efectivamente deja ejecutar el script pero manteniendo los permisos de apache, los que se llaman con sudo siguen sin ejecutarse

Bueno ya busqué por algunos blogs y definitivamente el problema es el selinux tal como decías.

Intenté hacerle un bypass como se recomendaba en algunos lados pero sin éxito:

Ahora... entiendo que por todos lados está muy restringido que un script via http se ejecute como root desde el mismo servidor hasta los sistemas de protección del mismo sistema operativo, por lo cual podría decirse que no debería hacerlo, pero entonces como lo hago si necesito que dependiendo de ciertas solicitudes http se generen acciones inmediatas a bajo nivel como cambiar la configuración de balanceos de carga, baneos por firewall, etc, no me sirve crear un log y listo, necesito que el sistema sea proactivo y rwactivo, esto quiere decir que si existe una solicitud peligrosa el usuario quede baneado al instante y no esperar a que un daemon barra un log.

En ese caso que sería mas óptimo? crear un servicio que reciba comandos? porque al final igual de todas maneras el servicio web va a tener que gatillar acciones como root, asi que no entiendo como debería hacerse sin arriesgar la seguridad de todo el sistema, no quiero tener que deshabilitar selinux.

O será que esta es una excepción a la regla?

creo que tendré que ir replanteandome si hacer esto via nginx y apache o snort directamente, veré si snort tiene la capacidad de ejecutar cosas dependiendo de cada regla.

En orden sería:

system('/var/ban/403.sh');
# sh: /var/ban/403.sh: Permission denied
 
system('/bin/bash /var/ban/403.sh');
# /bin/bash: /var/ban/403.sh: Permission denied
 
system('sudo /var/ban/403.sh');
# sudo: unable to open audit system: Permission denied
 
system('sudo /bin/bash /var/ban/403.sh');
# sudo: unable to open audit system: Permission denied

Definitivamente el sudoers no funciona , el script en php corre con permisos de "apache" y el sudoers está habilitado para ejecutar cualquier cosa sin contraseña con sudo y nada. Cuando resulte bien dejo habilitado solo los scripts necesarios.

Pues no, aplico todos los cambios, reinicio el servidor (es centos 7) y nada, el script me dice que el id es apache y es el httpd el que está ejecutando el script en php, nginx lo único que hace es hacer de reverse proxy nada mas porque la configuración para interactuar con scripts dinámicos es mas complejo, generalmente debes usar servicios paralelos con sockets de comunicación, al final nginx nunca ejecuta finalmente el script sino el servicio de cgi, en ese caso supongo que httpd hace lo mismo pero de manera mas ordenada, nativa y automatizada, por eso mejor dejé ambos instalados.

open_basedir puede se eh, lo revisaré ahora mismo aunque por defecto debería poderse.

Agregué al /etc/sudoers la linea:

Ahora ejecuto desde php:

<plaintext>
<?php 
system('id');
system('/var/ban/403.sh');
system('/bin/bash /var/ban/403.sh');
system('sudo /var/ban/403.sh');
system('sudo /bin/bash /var/ban/403.sh');
?>

el archivo 403.sh tiene:


Le di permisos de ejecución con chmod +x 403.sh y nada, solo se ejecuta el primero con id de apache:

Pero el resto nada apache está corriendo con permisos de apache y nginx con permisos de nginx, supuse que php al tener permisos de apache podría ejecutar el script de baneo con permisos de root pero nada.

Le acabo de poner:
A sudoers para descartar un problema con la ruta o cosas así y tampoco :-/

Bueno, hice funcionar fast cgi wrap pero el binario está compilado para que no se pueda iniciar en modo root y el lua está dificil de instalar ya que requiere la instalacion manual de versiones especificas de paquetes y no es bueno si quiero automatizar su instalación.

Lo que hice fue instalar httpd y php y lo hice correr en modo root y desde nginx hice que cuando se produjera un error 403 hiciera un reverse proxy a localhost puerto 81 a la ruta del 403.php y php es el encargado de hacer todo, es mas, ahora puedo utilizar mongodb con php directo o migrar a futuro a oracle si es necesario y httpd blindado unicamente en localhost.

Me salió muy larga la vuelta que quería hacer pero finalmente fue efectivo, tampoco creo que haya problema de carga con apache ya que las solicitudes se harán unicamente cuando se haga un baneo o algo por el estilo.

Gracias de todas maneras, a futuro buscaré una manera mas facil de hacer todo sin tener que pasar por el httpd y un doble reverse proxy xd

Ahora intentaré hacer lo que dice moikano→@ para no tener que usar todo en modo root sino solo los scripts necesarios.

Saludos.