Re: Documenting ptrace access mode checking

[Jann Horn <jann@thejh.net>]

[-- Attachment #1: Type: text/plain, Size: 3075 bytes --]

On Thu, Jun 23, 2016 at 09:42:09AM +0200, Michael Kerrisk (man-pages) wrote:
> Hi Jann,
> 
> Thanks for your further review. Follow-up of one point below.
> 
> On 06/23/2016 12:44 AM, Jann Horn wrote:
> >On Wed, Jun 22, 2016 at 09:21:29PM +0200, Michael Kerrisk (man-pages) wrote:
> >>On 06/21/2016 10:55 PM, Jann Horn wrote:
> >>>On Tue, Jun 21, 2016 at 11:41:16AM +0200, Michael Kerrisk (man-pages) wrote:
> 
> [...]
> 
> >>>>      The  algorithm  employed for ptrace access mode checking deter‐
> >>>>      mines whether the calling process is  allowed  to  perform  the
> >>>>      corresponding action on the target process, as follows:
> >>>>
> >>>>      1.  If the calling thread and the target thread are in the same
> >>>>          thread group, access is always allowed.
> >>>>
> >>>>      2.  If the access mode specifies PTRACE_MODE_FSCREDS, then  for
> >>>>          the  check in the next step, employ the caller's filesystem
> >>>>          user ID and group ID (see credentials(7));  otherwise  (the
> >>>>          access  mode  specifies  PTRACE_MODE_REALCREDS, so) use the
> >>>>          caller's real user ID and group ID.
> >>>
> >>>Might want to add a "for historical reasons" or so here.
> >>
> >>Can you be a little more precise about "here", and maybe tell me why
> >>you think it helps?
> >
> >I'm not sure, but it might be a good idea to add something like this at the
> >end of 2.:
> >"(Most other APIs that check one of the caller's UIDs use the effective one.
> >This API uses the real UID instead for historical reasons.)"
> >
> >In my opinion, it is inconsistent to use the real UID/GID here, the
> >effective one would be more appropriate. But since the existing code uses
> >the real UID/GID and that's not a security issue for existing users of
> >the ptrace API, this wasn't changed when I added the REALCREDS/FSCREDS
> >distinction.
> >
> >I think that for a reader, it might help to point out that in most cases,
> >when a process is the subject in an access check, its effective UID/GID
> >are used, and this is (together with kill()) an exception to that rule.
> >But you're the expert on writing documentation, if you think that that's
> >too much detail / confusing here, it probably is.
> 
> Okay -- got it now, I think. I made this text:
> 
>        2.  If the access mode specifies PTRACE_MODE_FSCREDS, then, for
>            the check in the next step, employ the caller's  filesystem
>            UID  and  GID.  (As noted in credentials(7), the filesystem
>            UID and GID almost always have the same values as the  cor‐
>            responding effective IDs.)
> 
>            Otherwise, the access mode specifies PTRACE_MODE_REALCREDS,
>            so use the caller's real UID and GID for the checks in  the
>            next  step.  (Most APIs that check the caller's UID and GID
>            use  the  effective  IDs.   For  historical  reasons,   the
>            PTRACE_MODE_REALCREDS check uses the real IDs instead.)

Thanks, that sounds good.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]