¿Cuáles son los permisos perfectos de Unix para los directorios de proyectos web habituales?

¿Cuáles son los permisos mínimos perfectos en formato octal para los siguientes en una aplicación web escrita?

1. Un directorio donde residirá el usuario que cargó archivos estáticos (imágenes / archivos swf / js)
2. Un directorio donde residirán los archivos estáticos cargados por el administrador (archivos images / swf / js)
3. Un directorio donde residen las bibliotecas utilizadas en la aplicación
4. Un directorio donde residirán los scripts del lado del servidor ejecutable / navegable
5. Un directorio donde los archivos ya existentes (txt o xml) serán editados por código en el lado del servidor

Aquí están mis sugerencias y justificaciones.

1. 555, todos pueden leer y escribir, nadie puede ejecutar
2. 544, el propietario solo puede escribir, todos los demás solo pueden leer, nadie puede ejecutar
3. 000, nadie necesita leer, escribir ni ejecutar, ¿solo será utilizado por el servidor web?
4. 661, el propietario puede leer, escribir, todos los demás solo pueden ejecutar
5. 600, el propietario puede leer, escribir (puede que no sea necesario), nadie más puede hacer nada

Ahora estoy interesado en dos cosas:

1. ¿Hay algo de uso común en las aplicaciones basadas en la web que me haya perdido en la primera lista?
2. ¿Hay algo con lo que no esté de acuerdo en la segunda lista, cuál es su alternativa y por qué es mejor?

Suponiendo que una 'aplicación web' se ejecuta en un servidor (como apache, nginx, etc.) y está escrita en algún lenguaje de secuencias de comandos dinámico (como PHP, Ruby, etc.), tiene un malentendido sobre quién es el 'usuario'.

El usuario no es la persona que ha iniciado sesión en su aplicación; eso, y su papel en la aplicación (administrador, etc.) es completamente irrelevante para el escenario. El usuario es el usuario del sistema Linux con el que se ejecuta el proceso. El código de su sitio web se ejecuta como un solo usuario: puede ser el usuario de su servidor web (lo cual no es realmente bueno), o puede ser un usuario específico de su sitio (que es mucho mejor).

En Linux, los usuarios pertenecen a grupos: podemos agregar un usuario a otro grupo y asignar privilegios a ese grupo.

Una buena configuración hará que su servidor se ejecute como un solo usuario (llamemos a este usuario 'servidor web') y que su lenguaje de script dinámico se ejecute (por ejemplo, a través de FastCGI) como su propio usuario (un usuario por sitio; llamemos a nuestro primer usuario 'sitio1') .

Para servir sus archivos, el servidor web necesita acceso a ellos, y el lenguaje de secuencias de comandos necesita acceso a ellos. Eso significa que 'sitio1' y 'servidor web' deben poder leer sus archivos. Sin embargo, solo uno de ellos puede 'poseer' los archivos. El propietario es el 'usuario' (en usuario, grupo, otro). También necesitamos nuestro lenguaje de secuencias de comandos para poder escribir en el directorio (y leer los archivos que ha escrito). Por lo tanto, el usuario 'sitio1' necesita permisos de lectura y escritura. Dado que queremos que los permisos grupales y de otro tipo sean lo más restrictivos posible, nuestro 'propietario' será 'sitio1', y los permisos de usuario correspondientes serán de lectura y escritura.

Como no podemos especificar los permisos para nuestro servidor web como otro 'usuario', agregaremos 'servidor web' al grupo 'sitio1' (por supuesto, podría crear un grupo diferente con 'sitio1' y 'servidor web' en él. Todos los miembros de este grupo tendrán los mismos permisos. Los permisos más laxos (del usuario, grupo u otro conjunto) se aplicarán a cualquier usuario para determinar sus permisos.

Vale la pena señalar que una buena configuración no debería requerir que los archivos tengan permisos de ejecución para un lenguaje dinámico. Los archivos no se ejecutan directamente, sino que se leen en un intérprete; solo se necesitan permisos de lectura para ejecutar un script típico (uno que no escriba nada).

El permiso 'ejecutar' en los directorios tiene un significado diferente: permite el recorrido sin poder leer el contenido. Para poder leer un archivo en un directorio, un usuario debe tener permisos de 'ejecución' en CADA directorio arriba de él.

Para una aplicación web, cada archivo debe tener permisos de lectura de su propietario; de lo contrario, es un archivo bastante inútil. Ya sea que un usuario o un administrador cargue archivos (a través de su aplicación web), el 'propietario' (es decir, el lenguaje dinámico) necesita permisos de escritura. Una configuración eficiente intentará servir archivos estáticos directamente a través del servidor web, ya que los lenguajes dinámicos tienden a ser lentos para leer en archivos grandes y reproducir los contenidos. Por lo tanto, el servidor web necesita acceso de lectura a sus archivos estáticos.

Por lo tanto, los permisos mínimos de archivo pueden ser:

• Un archivo en un directorio donde residirá el usuario archivos estáticos cargados (imágenes / archivos swf / js): 640
• Un archivo en un directorio donde residirán los archivos estáticos cargados por el administrador (archivos images / swf / js): 640
• Un archivo en un directorio donde residen las bibliotecas utilizadas en la aplicación: 400 (o 440)
• Un archivo en un directorio donde residirán los scripts del lado del servidor ejecutable / navegable: 400 (o 440)
• Un archivo en un directorio donde los archivos ya existentes (txt o xml) serán editados por código en el lado del servidor: 640 o 600
  • (depende de si el servidor web mostrará estos, sin modificar a veces)

Mientras, los permisos mínimos de directorio pueden ser:

• Un directorio donde residirá el usuario que cargó archivos estáticos (imágenes / archivos swf / js): 750
• Un directorio donde residirán los archivos estáticos cargados por el administrador (archivos images / swf / js): 750
• Un directorio donde residen las bibliotecas utilizadas en la aplicación: 500 (o 550) [debería ser 510 al menos]
• Un directorio donde residirán los scripts del lado del servidor ejecutable / navegable: 500 (o 550) [debería ser 510 al menos]
• Un directorio donde los archivos ya existentes (txt o xml) serán editados por código en el lado del servidor: 750 o 700
  • (depende de si el servidor web servirá archivos desde aquí, a veces sin modificar)

Una vez más, su servidor web debe tener permisos de 'ejecución' en cada directorio por encima del que necesita acceso, por lo que incluso si el servidor web no sirve archivos de un directorio determinado, deberíamos otorgarle permisos de ejecución.

Es bastante común otorgarle al servidor web acceso de lectura a la mayoría de los archivos (así que cambie esos 500 a 550). Los permisos predeterminados 'algo seguros' son comúnmente 755 para directorios y 644 para archivos (sin permisos de ejecución, todos pueden leer y solo el usuario puede escribir), notará que la gran mayoría de los archivos en un sistema Linux tienen estos permisos.

Tenga en cuenta que los "otros" permisos se refieren a cualquier usuario del sistema que no sea el propietario o el grupo (es decir, todos los usuarios restantes del sistema). Mantener sus 'otros' permisos restrictivos es bueno, porque estos usuarios son desconocidos, no les ha dado permiso explícitamente. Los otros permisos son a menudo los más fáciles de aprovechar en un sistema comprometido (por ejemplo, una de las razones por las que / tmp es un objetivo común).

En el contexto de lo anterior, no creo que sus dos últimas preguntas sean tan relevantes. Establezca sus permisos de directorio en 550 (y los permisos de archivo en 440), y luego otorgue al usuario permisos de escritura para los directorios en los que su aplicación escribirá (es decir, directorio: 750; archivo: 640).

(Obviamente, necesitará permisos de escritura para cargar los archivos, pero si lo desea, puede eliminarlos después, sin embargo, posiblemente, si alguien está escribiendo en un directorio en el que solo el propietario puede escribir, su cuenta se ha visto comprometida, lo cual es uno de las razones para mantener permisos restrictivos).

Es normal tener el conjunto mínimo de permisos para realizar el trabajo. Si tiene su servidor web y los usuarios comparten un grupo común, entonces puede eliminar la necesidad de dar acceso o. Los permisos también están relacionados con los usuarios. Parece haber entendido mal los permisos octales.

1. 555 r-xr-xr-xno lo es rw-rw-rw. Como se trata de un directorio, para crear / eliminar archivos, debe haber xconfigurado, por lo que 750 rwxr-x---sería un buen lugar para comenzar. Esto permite que el usuario propietario del directorio agregue / elimine archivos y que todos en el grupo común puedan acceder a ellos.
2. Lo mismo que 1. arriba.
3. Si son realmente archivos estáticos, 050 le daría acceso al servidor web, sin embargo, para crear los archivos en primer lugar, 750 sería un mínimo.
4. Lo mismo que 3 arriba.
5. 070 sería el mínimo para permitir que el servidor web lea y cambie los archivos, pero los archivos deben crearse para que 770 sea probablemente más realista.

En general, se usaría el modo 0755, 0775 o 2775 en los directorios (el bit SGID en los directorios, para BSD y para Linux si el sistema de archivos está montado con la semántica BSD hará que la asociación grupal de nuevos archivos coincida con la configuración del directorio principal en lugar de GID predeterminado del creador del archivo). Esto permite a todos los usuarios recorrer (chdir dentro y a través) y leer (ejecutar el comando ls o realizar las llamadas al sistema readdir / read) los directorios en cuestión. Las alternativas agregan opciones de grupo / escritura y, como se señaló, el bit SGID, en los directorios, puede ayudar a mantener todos los archivos y subdirectorios asociados con un grupo adecuado.

Para los archivos, normalmente se usaría 0644 o posiblemente 0664 (legible en todo el mundo y escribible en grupo o no). Obviamente, para los scripts y binarios CGI, uno debe agregar el bit x; y para algunas situaciones especiales, con binarios extremadamente bien probados, uno podría agregar bits SUID o SGID. Normalmente, UNIX y Linux ignorarán el bit SUID / SGID en los scripts y solo respetarán su semántica para los binarios ejecutables compilados nativos. Sin embargo, es posible que esté ejecutando su sitio bajo algo como Apache con algún módulo como el "setuidhack" que puede usarse para hacer que el servidor web respete los bits SUID / SGID incluso en scripts interpretados. (Esto se realiza mediante el daemon HTTP stat () en cada archivo y utilizando su propio código fork () / execve () personalizado, interpolando la cadena de intérprete correcta en el vector execve () en lugar de simplemente pasar el ejecutable '

Esas son solo las pautas más generales. No son "perfectos" para todas las situaciones y definitivamente debe consultar los documentos de su servidor web y cualquier aplicación web o marcos que esté instalando y configurando ... y probablemente desee consultar con un experto en seguridad de UNIX antes de exponga cualquiera de sus archivos, códigos o servidores a Internet público.