¿Eliminar privilegios después del inicio o iniciar como usuario sin privilegios?

4

Dado que un servicio necesita acceso a algunos secretos de un archivo de configuración para comenzar, puedo imaginar tres enfoques:

1) Mantenga el archivo legible solo por root. Inicie el proceso como root, lea los privilegios de configuración y eliminación.

2) Mantenga el archivo legible solo para el usuario del demonio, inicie el proceso como el usuario del demonio.

3) Mantenga el archivo legible solo por root. Inicie el proceso como usuario demonio con la capacidad CAP_DAC_READ_SEARCH y suéltelo después de leer la configuración.

Mi análisis inicial de las alternativas:

Opción 1

+ Si existe una vulnerabilidad, un atacante necesita leer su propia memoria de proceso para obtener datos confidenciales (¿bastante difícil?)

- Más complejo debido a la necesidad de setuid / setgid

: si el software se ve comprometido antes de eliminar los privilegios, se ejecutará como root

Opción 2

+ más sencillo de programar, elimine los privilegios del script de inicio

- Si existe una vulnerabilidad, un atacante puede leer datos confidenciales del disco (fácil)

Opción 3

+ Nunca da acceso de root completo al proceso

+ Si hay un error, un atacante tendría que leer la memoria de proceso en lugar de solo un archivo

- Mucho complejo

- Todavía ofrece un acceso muy amplio para leer archivos fuera del archivo de configuración (como /etc/shadow y similar)

¿Hay otras opciones que deban considerarse, o ventajas o desventajas que haya omitido? ¿Hay alguna buena razón para manejar la eliminación de privilegios en lugar de dejar que el proceso init lo maneje?

    
pregunta thusoy 19.02.2017 - 06:33
fuente

1 respuesta

2

Evite dar los privilegios de daemon que no necesita, incluso para el inicio. Esto descarta las opciones 1 y 3. Sin embargo, no significa que tenga que ir a la opción 2.

Primero, permítame recordar lo básico, por si acaso:

  • Ejecuta el demonio como un usuario dedicado, que solo ejecuta este servicio.
  • No permita que el demonio modifique sus archivos de configuración. Esto significa que todos los archivos de configuración deben ser propiedad de un usuario diferente. El soporte para ACL es ubicuo en estos días, por lo tanto, root o algún otro usuario es el propietario de los archivos de configuración, y usa una ACL para permitir que el usuario o grupo del daemon los lea.

El hecho de que haya un beneficio significativo para evitar que el daemon lea los archivos de configuración confidenciales después del inicio depende de para qué utiliza la información confidencial y qué más hace. Si estas son las credenciales que el demonio usa solo una vez durante el inicio y luego las borra de la memoria, hay un beneficio para hacer que sea imposible leerlas más tarde. Si los datos confidenciales permanecen en la memoria, no hay mucho beneficio, pero también depende de cuál sea el más probable: un exploit que permita la divulgación de la memoria pero no la ejecución de código arbitrario (por ejemplo, memoria no inicializada o un indicador incorrecto, aunque generalmente permiten la arbitración). Ejecución del código), o un exploit que permite la divulgación de archivos pero la ejecución de código arbitrario de puntos (por ejemplo, desinfección de ruta incorrecta).

Si decide que la protección de no permitir que el daemon lea el archivo confidencial después del inicio es beneficiosa, entonces deje que el sistema de inicio administre la eliminación de privilegios. Abra el archivo de configuración del proceso supervisor, luego elimine el privilegio asociado (un grupo suplementario, presumiblemente), y pase el descriptor de archivo al proceso ( --sensitive-config-fd=3 o --sensitive-config-file=/dev/fd/3 ).

    
respondido por el Gilles 19.02.2017 - 12:12
fuente