/proc/*/fd/ and sys_ptrace

[Vreixo Formoso]

Hi,

I'm not sure this is really a bug, but I did not find another place to comment this out...
When creating a profile for chromium-browser, I did notice capability sys_ptrace was need or the browser just didn't work. This is unfortunate, as if I understand things right, sys_ptrace allows arbitrary modification of other process memory (even unconfined processes), thus bypassing any security restriction the profile may have.
As executable inspection showed no call to ptrace(), I have been researching a bit further to find why this capability was needed. After inspecting chromium source code I found the reason: as part of chromium sandbox model, a tiny setuid executable explores /proc/*/fd/ of each process owned by the user (not the root, but the user that executes the suid binary), in order to find a process (identified because it has opened a given socket).
Well, so the question is: why reading /proc/*/fd/ requires sys_ptrace capability, and not just a read access to this directory in the profile? Is that an AppArmor feature, or is that capability enforced by the kernel? If so, do you know why? It seems to me that just knowing what files a process has opened it's far from the ability to really ptrace it...
Well, looking further I found there was a similar issue with firefox (see bug #498317), that is reported to be fixed. So, why am I having the same issue (I'm running and up-to-date lucid). It might be related to the fact the process is an setuid executable, and thus the /proc/*/fd/ it attemps to read is owner by an user different that its effective uid?
If so, is this really a bug, or the sys_ptrace requirement is a desired feature? Wouldn't an entry like "/proc/*/fd/ r" (vs an "owner /proc/*/fd/ r") be enough?

Finally, if this is not really a bug, do you know where can I ask for this question? Thanks in advance.

Vreixo

[John Johansen (jjohansen)]

This is a really unfortunate side effect of how the linux kernel determines permissions for access to files in /proc/*/fd/. The /proc code directly calls the kernel function ptrace_may_access() which in turn will call the security_ptrace_access_check() hook. This means that AppArmor (any LSM module actually) receives a ptrace permission check that is indistinguishable from a true ptrace permission check. The request for the file path comes through later and will also be required for the profile.

The net effect is that /proc/*/fd/* r, is necessary but not sufficient and capability sys_ptrace is also required. There is currently work in progress to help mitigate this but it is not available on the Lucid kernel. There is however a way to partially mitigate this issue within a chromium profile.

The binary that does the actual reading of /proc/*/fd/* is done by a separate setuid executable. If you set up a separate profile for that executable it will move capability sys_ptrace out of the chromium profile and isolate it in the profile for the setuid executable.

[Vreixo Formoso (metalpain2002)]

> If you set up a separate profile for that executable it will move capability sys_ptrace out of the chromium profile

Yeah, that was what I did. Ugly behavior anyway...

btw, given your explanation, I'm marking this bug as invalid. I will review changes of future apparmor releases to see if this issue was mitigated.

Thanks,
Vreixo