Derechos de límite para aplicaciones de usuario

Question

Derechos de límite para aplicaciones de usuario

#1 de Austin Hemmelgarn (3 votos)

2

Tengo un sitio web, donde los usuarios están disponibles para cargar pequeñas aplicaciones que se ejecutan 24/7 en mi servidor.

Entonces, si el usuario carga una aplicación, se crearán algunas carpetas:

/{USER_ID}/{APP_ID}/

(si la carpeta de usuario ya existe, la carpeta /{USER_ID}/ no se volverá a crear)

Dentro de este directorio, los archivos de la aplicación serán almacenados. Para cada aplicación que el usuario cree, se creará un archivo bash dentro de la carpeta /{APP_ID}/ que contiene el comando de inicio de la aplicación.

Por ejemplo, si el usuario carga una aplicación. NET Core , se creará un archivo bash que contiene nohup dotnet app.dll ... .

Mi pregunta es cómo puedo asegurar mi servidor de la mejor manera para limitar los derechos de las aplicaciones del usuario.

Si el usuario creó la aplicación, puede hacer clic en el botón de inicio en el sitio web que ejecutará el archivo start.sh bash.

¿Qué sucede si la aplicación que el usuario cargó cambia el contenido del archivo bash que puede dañar el servidor?

Quiero evitar eso haciendo que el archivo bash no sea editable / movible / eliminable, etc.

Pero supongo que puedes hacer más cosas malas para dañar el servidor.

Entonces, cómo puedo evitar que el usuario solo tenga derechos para hacer cosas dentro de su propia carpeta ( /{USER_ID}/ ) [solo usuario porque no me importa si el usuario daña sus propias aplicaciones].

Mi idea es que si el directorio ( /{USER_ID}/ ) se creará primero, php creará un usuario en mi servidor con solo derechos dentro de la carpeta /{USER_ID}/ .

¿Será esto lo suficientemente seguro?

Mi sistema operativo es Ubuntu 16.04.

php ubuntu laravel

pregunta xKushGene 17.10.2018 - 19:50

fuente

1 respuesta

Lea otras preguntas en las etiquetas php ubuntu laravel

Autentificación de contraseña y nombre de usuario de OpenVPN solamente - ¿inseguro? ¿Debemos cambiar el apetito por el riesgo cuando emprendemos un viaje de transformación digital?

score 3 · Answer 1

El simple hecho de aislar el acceso al sistema de archivos no es suficiente por sí solo para proteger al resto del sistema, y también es muy difícil hacerlo correctamente ( chroot se puede escapar con bastante facilidad, SELinux es un problema en la configuración, etc. ). Entre otros posibles medios de ataque tienes:

objetos IPC (semáforos, colas de mensajes POSIX, señales, etc.). No hay una manera fácil de limitar qué proceso puede manipular qué objetos de IPC, pero bloquearlos globalmente romperá muchos programas legítimos.
Acceso a la red. Esto es fácil de bloquear, pero obviamente no está cubierto solo por restringir el acceso al sistema de archivos.
Ciertos tipos de limitaciones de recursos son, en realidad, bastante fáciles de hacer de lado como usuario regular (por ejemplo, la afinidad de la CPU).
Sin ningún esfuerzo de su parte, sus nuevos usuarios tendrán acceso bastante fácil a ciertos tipos de hardware en el sistema.
Además de lo anterior, hay un lote de llamadas al sistema que nunca deben ser llamadas por el código de usuario regular pero que pueden ser ( vm86 y iopl son probablemente dos de los mejores ejemplos) ).

Lo ideal sería que, asumiendo que no desea lidiar con una configuración manual complicada, busque en una herramienta como firejail . Si bien no está diseñado para este caso de uso exacto, debería ser bastante trivial adaptarse a él, y es muy sencillo de configurar en comparación con la mayoría de los programas de sandbox. Con una configuración sensata, FireJail puede:

Restrinja de forma segura el acceso al sistema de archivos de una forma fácil de configurar.
Protege los objetos IPC de forma similar.
Restrinja el uso de capacidades.
Limite el acceso a la red, posiblemente utilizando una configuración de red completamente diferente del sistema host.
Forzar afinidad de CPU específica.
falsifique una variedad de información de identificación común para el sistema (nombre de host, ID de máquina, datos reportados por uname , etc.).
No permitir la ejecución de la memoria que puede escribirse (solo en algunas arquitecturas).
Deshabilite el acceso a una amplia variedad de hardware que de otra manera podría ser accesible.
Evita explícitamente la ejecución de código en ciertos directorios.
Haga que ciertos directorios sean efímeros (perderán su estado cuando se cierre la zona de pruebas, lo que es excelente para garantizar que los archivos temporales se limpien).
Establezca y aplique varios límites de uso de recursos para los procesos dentro del recinto de seguridad.
Bloquea explícitamente llamadas específicas al sistema (el perfil predeterminado con esto habilitado bloqueará la mayoría de las que no son necesarias para la mayoría de las aplicaciones y son un riesgo potencial de seguridad).