Seguimiento ejecutable sin permisos de lectura

Encontré un comportamiento sorprendente en Ubuntu 14.04 cuando lo uso straceen un ejecutable, sobre el que no tengo permiso de lectura. Me pregunto si esto es un error o si algún estándar exige este comportamiento oscuro.

Primero, veamos qué sucede cuando inicio un ejecutable ordinario en segundo plano y lo adjunto. Como se esperaba, esto funciona:

$ /bin/sleep 100 &
[2] 8078
$ strace -p 8078
Process 8078 attached
restart_syscall(<... resuming interrupted call ...>

Siguiente trato con un ejecutable, que no tengo permisos de lectura en:

---x--x--x 1 root root 26280 Sep  3 09:37 sleep*

No se permite adjuntar a este proceso en ejecución:

$ ./sleep 100 &
[1] 8089
$ strace -p 8089
strace: attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted

Esto también es lo que esperaría. Otorgar permiso de ejecución sin permiso de lectura no serviría de mucho, si simplemente pudiera adjuntar un depurador al proceso y efectivamente tener permisos de lectura en el ejecutable de esa manera.

Pero si inicio el ejecutable bajo un proceso ya trazado, se me permite hacerlo:

$ strace ./sleep 100
execve("./sleep", ["./sleep", "100"], [/* 69 vars */]) = 0
brk(0)                                  = 0x9b7a000

Esto es inesperado para mi. ¿Es esto un error de seguridad, o es una característica exigida por un estándar?

permissions strace

— kasperd
fuente

@ StéphaneChazelas: El punto es que él puede trazarlo, simplemente usándolo como argumento para alejarse. La causa raíz parece ser que en las execvellamadas, los permisos de lectura del archivo ejecutado no se verifican nuevamente si el proceso ya se ha rastreado. Su pregunta es si eso es un error de seguridad o una característica obligatoria (si este último, todavía lo consideraría un error de seguridad, solo un error de seguridad de la especificación).

— celtschk

@celtschk, lo siento, leí la pregunta demasiado rápido.

— Stéphane Chazelas

El EPERMparece venir de get_dumpable()(utilizado también para comprobar si se permite el volcado de memoria, por lo que "dumpable") llamada de __ptrace_may_access()llamada a partir ptrace_attach()de kernel/ptrace.c.

— ninjalj

Cuando se ejecuta un programa, ¿habrá suficiente información disponible para que el depurador genere un ejecutable ejecutable que contenga su código, o el cargador del programa descartará cosas como arreglos de reubicación que serían necesarios para que un programa realmente funcione?

— supercat

@supercat Hasta donde yo sé, el depurador tiene acceso a un solo paso a través de todo el código de modo de usuario que se está ejecutando, incluido el código de reubicación. Con ese nivel de acceso no debería ser demasiado difícil reproducir un ejecutable que funcione.

— kasperd

Esta no es una respuesta, sino una colección de enlaces y pensamientos en caso de que alguien más quiera estudiar también. Porque esto es algo bastante interesante.

La respuesta relacionada en Unix y Linux mencionando que es (o era, no se puede probar con el núcleo de vainilla en este momento) es posible volcar binarios de solo lectura de esta manera.

Grsecurity estaba tratando de solucionar este opción de configuración y el propio parche (Altough que puede haber cambiado desde entonces)

Esta confirmación realmente hace que parezca que los desarrolladores de kernel realmente solo se preocupan por volcar los binarios suid.

Pero en realidad de esta línea supongo kernel quiere impedir el dumping binarios regardles ilegibles de estado SUID. Y esta línea sugiere que los binarios que no son dumpables no deberían ser rastreables.

Entonces, a primera vista, parece que ha encontrado un error en el núcleo con implicaciones de seguridad. Pero no soy desarrollador de kernel, por lo que no puedo decirlo con certeza. Yo preguntaría en LKML.

Editar: un hallazgo más, con respecto al depurador, mencionado en los comentarios a la publicación original, desde el enderezado rápido (nuevamente) me parece que gdb usa los binarios rastreados y /proc/<pid>/mem. Una vez que el binario en ejecución no es legible, cat /proc/<pid>/memregresa EPERM. Si el binario es legible, vuelve EIO. (Probé esto en Ubuntu 14.10, que ejecuta varios parches de seguridad, por lo que esto podría ser diferente del núcleo de vainilla. De nuevo, no tengo el núcleo de vainilla ejecutándose en ningún lugar útil :()

— zorro
fuente