Escenarios de seguridad de permisos para un servidor web

Question

Escenarios de seguridad de permisos para un servidor web

#1 de symcbean (3 votos)
#2 de NuTTyX (1 votos)
#3 de Bryan Geraghty (1 votos)

2

Al tener /var/www/site.com de propiedad de www-data:www-data con un permiso de 750 para directorios y 640 para archivos, y tener mi usuario alexb agregado al grupo www-data , me encontré con problemas de permisos cuando trato de extraer nuevos liberaciones ( git pull ) al entorno de prueba.

Entonces, ahora mismo, las únicas soluciones que me vienen a la mente son las siguientes:

alexb:www-data de propiedad para /var/www/site.com con los mismos 750 y 640
Manténgase en www-data:www-data , y un diseño de permisos de 750 y 640.
Cree un nuevo usuario y grupo (staging-user: staging-group), dé a ese nuevo usuario acceso de shell real y asigne la propiedad de /var/www/site.com a ellos, con el diseño inicial de los permisos 750 y 640, de modo que cuando Necesito ejecutar las acciones de shell ( git pull por ejemplo) Simplemente cambio de usuario y lo hago.

Ahora, las preguntas son:

¿Qué es lo peor?
¿Alguna cosa importante que pueda extrañar?

linux permissions

pregunta w0rldart 11.08.2014 - 21:13

fuente

3 respuestas

Lea otras preguntas en las etiquetas linux permissions

¿Qué protección adicional se agrega a una API REST sobre HTTPS mediante el uso de algún tipo de HMAC? ¿Qué riesgos estoy tomando con una contraseña débil en una computadora portátil?

score 3 · Answer 1

Tener /var/www/site.com propiedad de www-data: www-data

Si www-data es también el uid que ejecuta su servidor web, entonces tiene un sistema realmente inseguro. El servidor web solo debe tener acceso de lectura (y ejecutar para directorios). Si necesita permitir que el servidor web escriba datos, entonces este directorio debe estar validado, y preferiblemente fuera de la raíz del documento.

Si alexb es la única cuenta que necesita acceso de escritura, entonces "alexb: www-data property for /var/www/site.com con los mismos 750 y 640" es un enfoque razonable. Sin embargo, si tiene varios usuarios que necesitan acceso de escritura, entonces la mejor solución es probablemente crear un nuevo grupo con ese acceso, permitir el acceso de lectura al servidor web como 'otro' (775/664), pero recuerde configurar los umasks del usuario de forma apropiada (y habilitar el bit setgid en el directorio (2775)

score 1 · Answer 2

xx4 en la carpeta es más como tener xx0 , ya que "otros" no podrán ver el contenido de ese directorio. Verían la carpeta, pero no podrán hacer nada con ella.

Como el servidor web probablemente no necesitará permisos de escritura, usaría alexb:www-data con 750 (directorios) y 640 (archivos), ya que de esta manera reduce los privilegios para el servidor web pero le permite usar tu usuario personal sin preocuparte demasiado.

Aparte de eso, debe configurar todas las carpetas g+s de permisos, por lo que incluso en el caso de que cree archivos como el usuario alexb , el servidor web todavía tendrá acceso a través de los permisos de grupo (asumo que su usuario alexb no tiene www-data como su grupo principal, por lo que usar ese permiso mantendría la identificación del grupo a través de los nuevos archivos).

Solo recuerda configurar UMASK de forma acorde (como 027 ), y no usa /var/www/site.com como el directorio de inicio del usuario.

Además, tenga en cuenta los sistemas de seguridad como SELinux (RedHat, CentOS, etc.).

score 1 · Answer 3

Te estás perdiendo la opción de ACLs. Linux tiene un sistema ACL muy flexible que la mayoría de las personas no considera. Escribí una entrada de blog sobre esto hace un tiempo:

enlace

Generalmente, establezco la propiedad y el grupo para el usuario shell y cualquier grupo de usuarios interactivos que necesiten poder actualizar esos archivos.

Luego uso mi grant-apache-read para permitir que el servidor web acceda a él:

source ~/lib/acl.bash; grantUserRead 'www-data' /var/www/site.come '*';

Dos cosas que deberás recordar al intentar esto:

Debe asegurarse de haber instalado setfacl
Asegúrese de que se está pasando al usuario correcto a la función
Necesitará el script ~ / lib / acl.bash
También creé una secuencia de comandos grant-apache-write para los directorios de caché y registro