J'ai trouvé un comportement surprenant sur Ubuntu 14.04 lors de l'utilisation strace
sur un exécutable, sur lequel je n'ai pas d'autorisation de lecture. Je me demande s'il s'agit d'un bug, ou si une norme impose ce comportement obscur.
Voyons d'abord ce qui se passe lorsque je démarre un exécutable ordinaire en arrière-plan et que je l'attache. Comme prévu, cela fonctionne:
$ /bin/sleep 100 &
[2] 8078
$ strace -p 8078
Process 8078 attached
restart_syscall(<... resuming interrupted call ...>
Ensuite, j'essaie avec un exécutable, sur lequel je n'ai aucune autorisation de lecture:
---x--x--x 1 root root 26280 Sep 3 09:37 sleep*
La connexion à ce processus en cours n'est pas autorisée:
$ ./sleep 100 &
[1] 8089
$ strace -p 8089
strace: attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted
C'est aussi ce à quoi je m'attendrais. Accorder une autorisation d'exécution sans autorisation de lecture ne serait pas très utile si je pouvais simplement attacher un débogueur au processus et avoir effectivement des autorisations de lecture sur l'exécutable de cette façon.
Mais si je démarre l'exécutable dans le cadre d'un processus déjà tracé, je suis autorisé à le faire:
$ strace ./sleep 100
execve("./sleep", ["./sleep", "100"], [/* 69 vars */]) = 0
brk(0) = 0x9b7a000
C'est inattendu pour moi. S'agit-il d'un bogue de sécurité ou s'agit-il d'une fonctionnalité mandatée par une norme?
EPERM
semble provenir get_dumpable()
(également utilisé pour vérifier si le dumping est autorisé noyau, donc « dumpable ») appelé à partir __ptrace_may_access()
appelée à partir ptrace_attach()
de kernel/ptrace.c
.
execve
appels, les autorisations de lecture du fichier exécuté ne sont pas vérifiées à nouveau si le processus est déjà tracé. Sa question est de savoir si c'est un problème de sécurité ou d' une fonction obligatoire (si celui - ci, je considère qu'il est encore un bug de sécurité, juste un bug de sécurité de la spécification).