On 2/25/21 2:04 AM, [email protected] wrote: > 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? >
the unconfined tracer does not need a ptrace rule, and a confined tracee can not currently block ptrace from an unconfined tracer. As for /proc/ access yes the profile can and does block that both with ptrace rules (if ptrace permission is requested) and with file rules. The exception of the tracee not being able to block unconfined is special and there may be a flag in the future to allow the tracee profile rule to override that. I should note that we can use different terminology if its easier. The tracer profile, is the subject type and the tracee profile is the object type. The profile it self is the same it just switches role depending on whether it is the task doing the tracing. As for /proc/ accesses, the task is always in the subject role. > 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. > you are right the only carte blanche is now the same thread group, I would have to dig way back into history to say anymore. That statement certainly could be tightened up. > 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). > correct > With best regards, > Harald > > -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
