Reading AppArmor's wiki article https://gitlab.com/apparmor/apparmor/-/wikis/TechnicalDoc_Proc_and_ptrace about the technical details of mediating access to certain /proc/ procfs elements as well as ptrace raises two questions for me:
1. section: ptrace and unconfined
How is "In the case of the tracer being unconfined no ptrace rule is needed." to be exactly interpreted? Does this mean that there is no ptrace rule necessary for the unconfined tracer -- which would be somehow obvious under the assumption that there is no explicit "unconfined" profile? Or am I misunderstanding here and this means that if the tracer is unconfined, the tracee profile cannot block ptrace and /proc/ access?
2. section: List of /proc files checking ptrace access
"It is also important to understand that the ptrace check may not always be performed when accessing one of the following /proc files, some of the checks are conditional and only performed when the cred or user, etc is different."
Now that really intrigues me purely for truely honest reasons and I looked at __ptrace_may_access(...) https://elixir.bootlin.com/linux/v5.11.1/source/kernel/ptrace.c#L275 what exactly is going on.
As far as I understand the code, the only immediate "card blanche" free access shortcut is in case of same thread group: __ptrace_may_access then grants access without consulting any LSM hook, including the integral CAP_SYS_PTRACE capabilitites "LSM" check.
However, all further checks, and especially tracer credential checks (UID/GID or FSUID/FSGID) agains the tracee's {,E,S}UID/{,E,S}GID, always tail into security_ptrace_access_check(...), thus invoking AppArmor's ptrace access check. I tried to cross-check with a Docker container started with "--pid host", but otherwise constrained by Docker's default container AppArmor profile and then trying to read /proc/1/environ. A parallel "dmsg -wH" clearly yields a fresh AppArmor originating audit access denial log.
Unless I'm missing something here (which well might be the case given the intricate and involved mechanics I'm facing here), then we wiki page for TechnicalDoc_Proc_and_ptrace should be updated (corrected): the only known case where the ptrace check isn't performed is for tracer and tracee being in the same thread group. "when the cred or user, etc is different" should be removed on the basis that even if this check is successful, further code execution still flows through AppArmor's ptrace security hook (as it also does if CAP_SYS_PTRACE is present).
With best regards,
Harald
-- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
