I found some surprising behavior on Ubuntu 14.04 when using strace on an executable, which I do not have read permission on. I wonder if this is a bug, or if some standard mandates this obscure behavior.
First let's see what happens when I start an ordinary executable in the background and attach to it. As expected this works:
$ /bin/sleep 100 &
[2] 8078
$ strace -p 8078
Process 8078 attached
restart_syscall(<... resuming interrupted call ...>
Next I try with an executable, which I have no read permissions on:
---x--x--x 1 root root 26280 Sep 3 09:37 sleep*
Attaching to this running process is not permitted:
$ ./sleep 100 &
[1] 8089
$ strace -p 8089
strace: attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted
This is also what I would expect. Granting execute permission without read permission wouldn't do much good, if I could simply attach a debugger to the process and effectively have read permissions on the executable that way.
But if I start the executable under an already traced process, I am permitted to do so:
$ strace ./sleep 100
execve("./sleep", ["./sleep", "100"], [/* 69 vars */]) = 0
brk(0) = 0x9b7a000
This is unexpected for me. Is this a security bug, or is it a feature mandated by a standard?
execvecalls, read permissions of the executed file are not checked again if the process is already traced. His question is whether that is a security bug or a mandated feature (if the latter, I'd still consider it a security bug, just a security bug of the specification). – celtschk Sep 3 at 9:05EPERMseems to come fromget_dumpable()(used also to check whether core dumping is allowed, thus "dumpable") called from__ptrace_may_access()called fromptrace_attach()onkernel/ptrace.c. – ninjalj Sep 3 at 10:06