Utilice de forma segura find con sudo

En un servidor Linux, necesito eliminar los privilegios de root de un grupo de usuarios. Pero esos usuarios tienen razones legítimas para poder usar la utilidad "buscar" para buscar archivos basados ​​en nombres de archivo, fechas de modificación y otros metadatos.

En el servidor, los nombres de los archivos no son confidenciales, pero el contenido del archivo sí.

Me gustaría usar sudo para permitir a los usuarios buscar archivos en cualquier parte del servidor. La utilidad "find" es excelente, pero permite todo tipo de efectos secundarios, como el uso de "-exec" para generar comandos arbitrarios.

¿Puedo findtrabajar con mis restricciones?

¿Qué hay de localizar ?

localizar lee una o más bases de datos preparadas por updatedb (8) y escribe nombres de archivos que coinciden con al menos uno de los PATRONES a la salida estándar, uno por línea. Si no se especifica --regex, los PATRONES pueden contener caracteres globales. Si algún PATRÓN no contiene caracteres globales, localizar se comporta como si el patrón fuera PATRÓN .

De forma predeterminada, localizar no verifica si los archivos encontrados en la base de datos todavía existen. localizar nunca puede informar archivos creados después de la actualización más reciente de la base de datos relevante.

O tal vez incluso inclinarse :

Secure Locate proporciona una forma segura de indexar y buscar rápidamente archivos en su sistema. Utiliza codificación incremental al igual que GNU localizar para comprimir su base de datos para acelerar la búsqueda, pero también almacenará los permisos y la propiedad de los archivos para que los usuarios no vean archivos a los que no tienen acceso.

Esta página del manual documenta la versión GNU de slocate. slocate Permite a los usuarios del sistema buscar sistemas de archivos completos sin mostrar archivos no autorizados.

De acuerdo a man 7 capabilities

   CAP_DAC_READ_SEARCH
          * Bypass file read permission checks and directory read and execute permission checks;
          * Invoke open_by_handle_at(2).

Esto funcionó para mí. (las líneas que comienzan con '#' son root, las que tienen '$' no son root) en este caso el usuario no root está en el wheelgrupo.

# cp /usr/bin/find /usr/bin/sudofind
# chmod 710 /usr/bin/sudofind
# chown root:wheel /usr/bin/sudofind
# setcap cap_dac_read_search+ep /usr/bin/sudofind
# exit
$ find /root 
find: ‘/root’: Permission denied
$ sudofind /root
/root /root 
/root/Testbed 
...
... 
$ sudofind /root -exec cat {} \;
cat: /root: Permission denied 
cat: /root/Testbed: Permission denied
$ sudofind /root -printf "%u %g %m %c %p\n"
root root 644 Mon Apr 20 09:20:48.0457518493 2015 /root
root root 755 Fri Dec  4 02:34:03.0016294644 2015 /root/Testbed
...
...
$ # Capability inheritance test..
$ sudofind /root -exec /bin/sleep 10 \; &
[1] 17017
$ getpcaps $(pgrep find)
Capabilities for `17017': = cap_dac_read_search+ep
$ getpcaps $(pgrep sleep)
Capabilities for `17019': =

Dado lo que otorga la capacidad, encaja exactamente con lo que desea. No he comprobado exhaustivamente si findtiene una característica que le permita leer bytes dentro de los archivos, pero cosas obvias como LD_PRELOADlos ataques de biblioteca y shim no deberían funcionar debido a la naturaleza de las comprobaciones de setuid en Linux, y los bits de capacidad no se obtienen heredado por procesos secundarios (a diferencia de setuid sin procesar), por lo que es otra ventaja.

Tenga en cuenta que lo que quiere hacer plantea posibles problemas de privacidad con respecto a la creación o acceso temporal de archivos, y el programa podría usarse como base para montar un intento de escalada de condición / privilegio de carrera (contra programas que crean nombres de archivo conocidos pero no hagas los controles de seguridad correctos).

Además, algunas aplicaciones mal escritas pueden depender de metadatos de archivo o estructura de árbol como una forma de transmitir significado u ocultar datos. Esto podría causar la liberación de información restringida o revelar documentos privilegiados desconocidos de otro modo (la seguridad a través de la oscuridad lo sé, pero esto es algo que a los proveedores de código cerrado en particular les gusta hacer, desafortunadamente).

Por lo tanto, tenga cuidado y tenga cuidado al hacerlo, y comprenda que todavía hay riesgos asociados con esto, incluso si las cosas obvias no funcionan.

¡Ah, y me interesaría ver si alguien tiene un ataque de prueba de concepto que utilice este mecanismo como base para la escalada de privilegios en los comentarios!

Les daría a los usuarios los permisos adecuados.

Por defecto, si la umask es 022, los directorios se crean para que todos puedan enumerar y registrar los archivos en ellos. De lo contrario, puede cambiar manualmente el permiso del directorio para que sea el bit a bit o de sus permisos antiguos y 0555:

chmod +0555 foo

Y si esos usuarios no tienen permiso de ejecución en todos los padres de ese directorio (por ejemplo, el directorio de inicio de otro usuario), probablemente significa que debe colocar el primer directorio en otro lugar.

Si solo desea permitir que algunos usuarios lean y ejecuten ese directorio, puede cambiar su modo a 0750, poner a esos usuarios en un grupo y cambiar el propietario del grupo del directorio a ese grupo:

groupadd can_read_foo
chmod 0750 foo
chgrp can_read_foo foo
gpasswd -a alice can_read_foo
gpasswd -a bob can_read_foo