Re: [PATCH 3/4] tst-pidfd.c: Test is UNSUPPORTED without PTRACE_MODE_ATTACH_REALCREDS

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

> On 27 Jun 2022, at 11:17, Mark Wielaard <mark@klomp.org> wrote:
> 
> Hi,
> 
> On Mon, Jun 27, 2022 at 01:51:41PM +0200, Christian Brauner wrote:
>> On Mon, Jun 27, 2022 at 01:14:06PM +0200, Florian Weimer via Libc-alpha wrote:
>>> * Mark Wielaard:
>>>> pidfd_getfd is mentioned (and allowed) by the seccomp filter, but the
>>>> syscall also needs the process to have PTRACE_MODE_ATTACH_REALCREDS
>>>> (which is really PTRACE_MODE_ATTACH | PTRACE_MODE_REALCREDS). Which it
>>>> doesn't have. If the process doesn't then pidfd_getfd is defined as
>>>> failing and setting errno to EPERM.
>>> 
>>> But what does it mean for a process to have PTRACE_MODE_REALCREDS?
>> 
>> #define PTRACE_MODE_ATTACH_REALCREDS (PTRACE_MODE_ATTACH | PTRACE_MODE_REALCREDS)
>> 
>> PTRACE_MODE_ATTACH_REALCREDS means
>> * PTRACE_MODE_REALCREDS which means cred->{g,u}id of the task are used
>>  for permission checking:
>> 
>> So it's a bit nasty here but roughly if the ptracer's real {g,u}id match
>> the target task's (ptracee's) effective, save, and real [g,u]id then
>> you'passed the first stage of permission checking.
>> 
>> If ptracer's [g,u]id aren't matching the ptracee's effective, saved, and
>> real [g,u]id the ptracer needs CAP_SYS_PTRACE in the ptracee's userns.
>> That will also get you past the first state of permission checking.
>> 
>> If both don't apply the request is denied with -EPERM.
>> 
>> The second stage of permission checking is:
>> (1) If the task isn't dumpable then you'll need CAP_SYS_PTRACE in the
>>    ptracee's mm user namespace. That userns may differ from the
>>    ptracee's current userns if the ptracee's userns wasn't privileged
>>    over the inode of the file it exec'ed and thus could be an ancestor
>>    userns (see would_dump()).
>> (2) The LSMs might deny your request.
> 
> Right, it is pretty difficult to determine why you got an EPERM.  But
> failing with EPERM is documented behaviour for pidfd_getfd, so IMHO if
> we get EPERM we should simply skip the test whatever the "real" reason
> is.

I agree, this is possible return code for the syscall so we should
handle it on testcase.

> 
> The ptrace manual page lists the whole (6 step) algorithm under
> "Ptrace access mode checking":
> https://man7.org/linux/man-pages/man2/ptrace.2.html
> 
> It also depends on (not) having CAP_SYS_PTRACE and the permission
> might be dependend on /proc/sys/kernel/yama/ptrace_scope
> 
> Cheers,
> 
> Mark
>