¿Por qué se recomienda crear un grupo y un usuario para algunas aplicaciones?

La mayoría de las veces, cuando se instala un programa desde la fuente, se recomienda crear un nuevo usuario y un nuevo grupo y otorgar /usr/local/<myapp>al usuario y al grupo recientemente creados la propiedad.

• ¿Por qué se considera esa práctica como una buena práctica?

• Que mejora

Ejemplo: usuario mysql / grupo mysql para el servidor de bases de datos MySQL.

La práctica no es crear un usuario y grupo por aplicación, sino por servicio. Es decir, los programas que ejecuta un usuario local no necesitan instalarse como un usuario que no sea root. Son demonios , programas que se ejecutan en segundo plano y que ejecutan solicitudes que llegan a través de la red u otros medios de comunicación, que deberían ejecutarse como un usuario dedicado.

El daemon se ejecuta como un usuario dedicado, de modo que si se comporta mal (debido a un error, probablemente provocado por un atacante), el daño que puede hacer es limitado: solo los archivos de datos del daemon se ven afectados (a menos que el atacante logre encontrar un agujero raíz local , que puede suceder). Por ejemplo, el daemon de la base de datos se mysqldejecuta como un usuario y grupo dedicado mysql:mysqly los archivos de datos de la base de datos ( /var/lib/mysql/*) pertenecen mysql:mysql.

Tenga en cuenta que el ejecutable del daemon y otros datos estáticos y archivos de configuración que se usan pero que no deben ser modificados por el daemon no deben pertenecer al usuario dedicado; deben ser propiedad de root:root, como la mayoría de los archivos de programa y configuración El mysqldproceso no tiene ninguna sobreescritura de negocio /usr/sbin/mysqldo /etc/mysql/my.cnf, por lo que estos archivos no deben pertenecer al mysqlusuario o ser modificable por el mysqlusuario o el mysqlgrupo. Si algunos archivos necesitan ser legibles solo por el demonio y el administrador, deben ser propiedad del usuario root y del grupo dedicado, y deben tener el modo 0640 ( rw-r-----).

Una categoría especial de ejecutables que no pueden ser propiedad de los root:rootprogramas son invocados por un usuario pero que necesitan ejecutarse con privilegios adicionales. Estos ejecutables deben ser setuid root si necesitan ejecutarse (al menos en parte) como root; entonces el ejecutable debe tener el modo 4755 ( rwsr-xr-x). Si el programa necesita privilegios adicionales pero no como root, entonces el programa debe establecerse de manera fija, de modo que los privilegios adicionales provengan de un grupo y no de un usuario. El ejecutable tiene el modo 2755 ( rwxr-sr-x). Las razones son dobles:

• No se debe permitir que el ejecutable se modifique a sí mismo, de modo que si un usuario logra explotar una vulnerabilidad, podría modificar los archivos de datos utilizados por el programa pero no inyectar un troyano en el ejecutable para atacar a otros usuarios que ejecutan el programa. .
• El archivo de datos del ejecutable pertenece al grupo. Un programa setuid tendría que cambiar entre el usuario real (el usuario que invocó el programa) para interactuar con el usuario y con el usuario efectivo (el usuario con el que se ejecuta el programa) para acceder a sus archivos de datos privados (la razón para ello tener privilegios adicionales). Además, un programa setgid puede segregar los datos por usuario a los que solo puede acceder el grupo (por ejemplo, almacenando archivos propiedad del usuario en un directorio al que solo pueda acceder el usuario root y el grupo del programa).

No son las aplicaciones en general, sino los demonios para los que sirve. La razón es que el demonio puede ejecutarse como un usuario sin privilegios en lugar de root, de modo que si tiene una vulnerabilidad de seguridad y se ve comprometido, el daño que se puede hacer está contenido solo en las áreas a las que el usuario tiene acceso.

La razón por la que se considera una buena práctica es evitar que otros usuarios del sistema anulen los datos y los archivos de configuración para la aplicación en particular.

A modo de ejemplo mysql/ mysqlsiendo el propietario del almacenamiento para cualquier persona MySQL los archivos de base de datos no impide el uso de la API de la aplicación de la corrupción de las bases de datos. Además, el usuario mysqlgeneralmente no tiene un shell real, por lo que nadie puede iniciar sesión como ese usuario tampoco.

Crear un nuevo grupo / usuario para un nuevo demonio instalado mejora la seguridad. Cuando el proceso del servidor se ejecuta bajo dicho usuario, está restringido a los derechos de acceso de ese usuario. En comparación: cuando se ejecuta como root, puede hacer todo.

Esta diferencia es importante en caso de que su demonio esté mal configurado y / o contenga un error relacionado con la seguridad.

No estoy seguro de lo que quiere decir con la segunda parte de su pregunta, es decir, la parte sobre la /usr/localpropiedad. En general, no tiene sentido que el mismo usuario Xbajo el que se ejecuta un daemon por razones de seguridad también posea el directorio con los archivos binarios (porque en ese caso podría cambiarlos en caso de un exploit). Pero el directorio con archivos de datos en los que trabaja el daemon debería ser accesible X: la forma más fácil de configurar esto es hacer que Xel propietario de los directorios / archivos de datos.

Ejecutar un demonio bajo su propio usuario especial es solo una técnica de seguridad, otras incluyen algún tipo de 'chrooting' o el uso del sistema de control de acceso obligatorio (MAC) (por ejemplo, SELinux).

Esta es una consideración de seguridad. Limita el daño que puede hacer alguien que irrumpe en una aplicación de demonio. La aplicación de usuario generalmente es propiedad de un ID de usuario estándar como root.

Si su servidor web, servidor de correo y base de datos se ejecutan como el mismo usuario, es más fácil comprometerlos. Si alguno de ellos tiene un error o una configuración incorrecta que permite el acceso al sistema, ese acceso se puede utilizar para acceder a las tres aplicaciones.

Si todos tienen cuentas separadas, como se recomienda, es probable que solo se pueda acceder a la aplicación comprometida. Si bien los detalles de configuración pública del otro pueden leerse, es poco probable que se puedan realizar cambios.

Muchos daemons permiten a los usuarios cargar y descargar archivos y, de lo contrario, hacer cosas que no quisiera que pudieran hacer en las configuraciones de otros daemons. Si cada aplicación tiene su propio ID de usuario y grupo, es más sencillo asegurar los demonios.

Tener un grupo específico de daemon simplifica la concesión segura de un acceso seguro de daemon de solo lectura a archivos y directorios. Si el archivo o directorio es propiedad de un usuario diferente, pero pertenece al grupo de demonios, generalmente será accesible de solo lectura. Los permisos de acceso se pueden verificar y corregir fácilmente con herramientas como find.