linux-kernel - Re: Documenting ptrace access mode checking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 24 Jun 2016 08:35:27 +0200
From:	Jann Horn <jann@...jh.net>
To:	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
Cc:	James Morris <jmorris@...ei.org>,
	linux-man <linux-man@...r.kernel.org>,
	Stephen Smalley <sds@...ho.nsa.gov>,
	lkml <linux-kernel@...r.kernel.org>,
	Kees Cook <keescook@...omium.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	linux-security-module <linux-security-module@...r.kernel.org>,
	Linux API <linux-api@...r.kernel.org>
Subject: Re: Documenting ptrace access mode checking

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.

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)