Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1427529 > unrolled thread

Documenting ptrace access mode checking

Started by"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
First post2016-06-21 11:50 +0200
Last post2016-06-24 10:40 +0200
Articles 5 on this page of 25 — 7 participants

Back to article view | Back to linux.kernel

Contents

  Documenting ptrace access mode checking "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-06-21 11:50 +0200
    Re: Documenting ptrace access mode checking ebiederm@xmission.com (Eric W. Biederman) - 2016-06-21 22:10 +0200
      Re: Documenting ptrace access mode checking Kees Cook <keescook@chromium.org> - 2016-06-21 22:40 +0200
        Re: Documenting ptrace access mode checking ebiederm@xmission.com (Eric W. Biederman) - 2016-06-21 23:20 +0200
        Re: Documenting ptrace access mode checking "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-06-22 21:30 +0200
      Re: Documenting ptrace access mode checking "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-06-22 21:30 +0200
        Re: Documenting ptrace access mode checking ebiederm@xmission.com (Eric W. Biederman) - 2016-06-23 21:20 +0200
          Re: Documenting ptrace access mode checking "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-06-24 12:00 +0200
      Re: Documenting ptrace access mode checking Oleg Nesterov <oleg@redhat.com> - 2016-06-23 00:00 +0200
        Re: Documenting ptrace access mode checking "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-06-23 09:10 +0200
          Re: Documenting ptrace access mode checking ebiederm@xmission.com (Eric W. Biederman) - 2016-06-23 21:10 +0200
            Re: Documenting ptrace access mode checking "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-06-24 10:20 +0200
    Re: Documenting ptrace access mode checking Jann Horn <jann@thejh.net> - 2016-06-21 23:30 +0200
      Re: Documenting ptrace access mode checking "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-06-22 21:30 +0200
        Re: Documenting ptrace access mode checking Kees Cook <keescook@chromium.org> - 2016-06-22 23:20 +0200
          Re: Documenting ptrace access mode checking "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-06-23 09:10 +0200
          Re: Documenting ptrace access mode checking "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-06-24 10:50 +0200
            Re: Documenting ptrace access mode checking Casey Schaufler <casey@schaufler-ca.com> - 2016-06-24 17:20 +0200
              Re: Documenting ptrace access mode checking Kees Cook <keescook@chromium.org> - 2016-06-24 22:10 +0200
              Re: Documenting ptrace access mode checking "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-06-25 09:30 +0200
        Re: Documenting ptrace access mode checking Jann Horn <jann@thejh.net> - 2016-06-23 00:50 +0200
          Re: Documenting ptrace access mode checking "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-06-23 09:50 +0200
            Re: Documenting ptrace access mode checking Jann Horn <jann@thejh.net> - 2016-06-24 08:40 +0200
    Re: Documenting ptrace access mode checking Stephen Smalley <sds@tycho.nsa.gov> - 2016-06-23 20:10 +0200
      Re: Documenting ptrace access mode checking "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-06-24 10:40 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1429192

FromJann Horn <jann@thejh.net>
Date2016-06-23 00:50 +0200
Message-ID<rMZ88-15H-77@gated-at.bofh.it>
In reply to#1429063

[Multipart message — attachments visible in raw view] — view raw

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:
> >>Here's the new ptrace(2) text. Any comments, technical or terminological
> >>fixes, other improvements, etc. are welcome.
> >
> >As others have said, I'm surprised about seeing documentation about
> >kernel-internal constants in manpages - but I think it might be a good
> >thing to have there, given that people who look at ptrace(2) are likely
> >to be interested in low-level details.
> 
> I agree that it is a little surprising to add kernel-internal
> constants in a man page. (There are precedents, but they are few.)
> But see my reply to Kees. It's more than just explaining low level
> details: there are various kinds of user-space behavior differences
> (real vs filesystem credentials; permitted vs effective capabilities)
> produced by the ptrace_may_access() checks, and those behaviors need
> to be described and *somehow* labeled for cross-referencing from
> other man pages.

Makes sense.


> >>       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.


> I changed this text to:
> 
>        Various parts of the kernel-user-space API (not just  ptrace(2)
>        operations), require so-called "ptrace access mode permissions"
>        which are gated by any enabled Linux Security Module (LSMs)—for
>        example,  SELinux,  Yama, or Smack—and by the the commoncap LSM
>        (which is always invoked).  Prior to  Linux  2.6.27,  all  such
>        checks  were  of a single type.  Since Linux 2.6.27, two access
>        mode levels are distinguished:

Sounds good to me.

[toc] | [prev] | [next] | [standalone]

#1429543

From"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Date2016-06-23 09:50 +0200
Message-ID<rN7yG-6MX-45@gated-at.bofh.it>
In reply to#1429192
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.)

[...]

Cheers,

Michael



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

[toc] | [prev] | [next] | [standalone]

#1430399

FromJann Horn <jann@thejh.net>
Date2016-06-24 08:40 +0200
Message-ID<rNsWt-4B1-11@gated-at.bofh.it>
In reply to#1429543

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#1430033

FromStephen Smalley <sds@tycho.nsa.gov>
Date2016-06-23 20:10 +0200
Message-ID<rNheF-5oI-7@gated-at.bofh.it>
In reply to#1427529
On 06/21/2016 05:41 AM, Michael Kerrisk (man-pages) wrote:
> Hi Jann, Stephen, et al.
> 
> Jann, since you recently committed a patch in this area, and Stephen,
> since you committed 006ebb40d3d much further back in time, I wonder if
> you might help me by reviewing the text below that I propose to add to
> the ptrace(2) man page, in order to document "ptrace access mode 
> checking" that is performed in various parts of the kernel-user-space
> interface. Of course, I welcome input from anyone else as well.
> 
> Here's the new ptrace(2) text. Any comments, technical or terminological
> fixes, other improvements, etc. are welcome.
> 
> [[
>    Ptrace access mode checking
>        Various parts of the kernel-user-space API (not just  ptrace(2)
>        operations), require so-called "ptrace access mode permissions"
>        which are gated  by  Linux  Security  Modules  (LSMs)  such  as
>        SELinux,  Yama,  Smack,  or  the  default  LSM.  Prior to Linux
>        2.6.27, all such checks were of a  single  type.   Since  Linux
>        2.6.27, two access mode levels are distinguished:
> 
>        PTRACE_MODE_READ
>               For  "read" operations or other operations that are less
>               dangerous, such as: get_robust_list(2); kcmp(2); reading
>               /proc/[pid]/auxv,         /proc/[pid]/environ,        or
>               /proc/[pid]/stat; or readlink(2) of  a  /proc/[pid]/ns/*
>               file.
> 
>        PTRACE_MODE_ATTACH
>               For  "write"  operations,  or  other operations that are
>               more    dangerous,    such    as:    ptrace    attaching
>               (PTRACE_ATTACH)    to   another   process   or   calling
>               process_vm_writev(2).   (PTRACE_MODE_ATTACH  was  effec‐
>               tively the default before Linux 2.6.27.)

That was the intent when the distinction was introduced, but it doesn't
appear to have been properly maintained, e.g. there is now a common
helper lock_trace() that is used for
/proc/pid/{stack,syscall,personality} but checks PTRACE_MODE_ATTACH, and
PTRACE_MODE_ATTACH is also used in timerslack_ns_write/show().  Likely
should review and make them consistent.  There was also some debate
about proper handling of /proc/pid/fd.  Arguably that one might belong
back in the _ATTACH camp.

> 
>        Since  Linux  4.5, the above access mode checks may be combined
>        (ORed) with one of the following modifiers:
> 
>        PTRACE_MODE_FSCREDS
>               Use the caller's filesystem UID  and  GID  (see  creden‐
>               tials(7)) or effective capabilities for LSM checks.
> 
>        PTRACE_MODE_REALCREDS
>               Use the caller's real UID and GID or permitted capabili‐
>               ties for LSM checks.  This was effectively  the  default
>               before Linux 4.5.
> 
>        Because  combining  one of the credential modifiers with one of
>        the aforementioned access modes is  typical,  some  macros  are
>        defined in the kernel sources for the combinations:
> 
>        PTRACE_MODE_READ_FSCREDS
>               Defined as PTRACE_MODE_READ | PTRACE_MODE_FSCREDS.
> 
>        PTRACE_MODE_READ_REALCREDS
>               Defined as PTRACE_MODE_READ | PTRACE_MODE_REALCREDS.
> 
>        PTRACE_MODE_ATTACH_FSCREDS
>               Defined as PTRACE_MODE_ATTACH | PTRACE_MODE_FSCREDS.
> 
>        PTRACE_MODE_ATTACH_REALCREDS
>               Defined as PTRACE_MODE_ATTACH | PTRACE_MODE_REALCREDS.
> 
>        One further modifier can be ORed with the access mode:
> 
>        PTRACE_MODE_NOAUDIT (since Linux 3.3)
>               Don't audit this access mode check.
> 
> [I'd quite welcome some text to explain "auditing" here.]

Some ptrace access mode checks, such as checks when reading
/proc/pid/stat, merely cause the output to be filtered/sanitized rather
than an error to be returned to the caller.  In these cases, accessing
the file is not a security violation and there is no reason to generate
a security audit record.  This modifier suppresses the generation of
such an audit record for the particular access check.

> 
>        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.
> 
>        3.  Deny access if neither of the following is true:
> 
>            · The real, effective, and saved-set user IDs of the target
>              match  the caller's user ID, and the real, effective, and
>              saved-set group IDs of  the  target  match  the  caller's
>              group ID.
> 
>            · The caller has the CAP_SYS_PTRACE capability.
> 
>        4.  Deny  access if the target process "dumpable" attribute has
>            a value other than 1 (SUID_DUMP_USER; see the discussion of
>            PR_SET_DUMPABLE  in prctl(2)), and the caller does not have
>            the CAP_SYS_PTRACE capability in the user namespace of  the
>            target process.
> 
>        5.  The  kernel LSM security_ptrace_access_check() interface is
>            invoked to see if ptrace access is permitted.  The  results
>            depend on the LSM.  The implementation of this interface in
>            the default LSM performs the following steps:
> 
>            a) If the access mode  includes  PTRACE_MODE_FSCREDS,  then
>               use the caller's effective capability set in the follow‐
>               ing  check;  otherwise  (the   access   mode   specifies
>               PTRACE_MODE_REALCREDS,  so)  use  the caller's permitted
>               capability set.
> 
>            b) Deny access if neither of the following is true:
> 
>               · The caller's capabilities are a proper superset of the
>                 target process's permitted capabilities.
> 
>               · The  caller  has  the CAP_SYS_PTRACE capability in the
>                 target process's user namespace.
> 
>               Note that the default LSM does not  distinguish  between
>               PTRACE_MODE_READ and PTRACE_MODE_ATTACH.
> 
>        6.  If  access  has  not  been  denied  by any of the preceding
>            steps, then access is allowed.
> ]]
> 
> There are accompanying changes to various pages that refer to 
> the new text in ptrace(2), so that, for example, kcmp(2) adds:
> 
>        Permission  to  employ kcmp() is governed by ptrace access mode
>        PTRACE_MODE_ATTACH_REALCREDS checks against both pid1 and pid2;
>        see ptrace(2).
> 
> and proc.5 has additions such as:
> 
>        /proc/[pid]/auxv (since 2.6.0-test7)
>               ...
>               Permission to access this file is governed by  a  ptrace
>               access    mode   PTRACE_MODE_READ_FSCREDS   check;   see
>               ptrace(2).
> 
>        /proc/[pid]/cwd
>               ...
>               Permission to dereference  or  read  (readlink(2))  this
>               symbolic  link  is  governed  by  a  ptrace  access mode
>               PTRACE_MODE_READ_FSCREDS check; see ptrace(2).
> 
> Thanks,
> 
> Michael
>

[toc] | [prev] | [next] | [standalone]

#1430461

From"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Date2016-06-24 10:40 +0200
Message-ID<rNuOB-5IF-13@gated-at.bofh.it>
In reply to#1430033
Stephen,

On 06/23/2016 08:05 PM, Stephen Smalley wrote:
> On 06/21/2016 05:41 AM, Michael Kerrisk (man-pages) wrote:
>> Hi Jann, Stephen, et al.
>>
>> Jann, since you recently committed a patch in this area, and Stephen,
>> since you committed 006ebb40d3d much further back in time, I wonder if
>> you might help me by reviewing the text below that I propose to add to
>> the ptrace(2) man page, in order to document "ptrace access mode
>> checking" that is performed in various parts of the kernel-user-space
>> interface. Of course, I welcome input from anyone else as well.
>>
>> Here's the new ptrace(2) text. Any comments, technical or terminological
>> fixes, other improvements, etc. are welcome.
>>
>> [[
>>    Ptrace access mode checking
>>        Various parts of the kernel-user-space API (not just  ptrace(2)
>>        operations), require so-called "ptrace access mode permissions"
>>        which are gated  by  Linux  Security  Modules  (LSMs)  such  as
>>        SELinux,  Yama,  Smack,  or  the  default  LSM.  Prior to Linux
>>        2.6.27, all such checks were of a  single  type.   Since  Linux
>>        2.6.27, two access mode levels are distinguished:
>>
>>        PTRACE_MODE_READ
>>               For  "read" operations or other operations that are less
>>               dangerous, such as: get_robust_list(2); kcmp(2); reading
>>               /proc/[pid]/auxv,         /proc/[pid]/environ,        or
>>               /proc/[pid]/stat; or readlink(2) of  a  /proc/[pid]/ns/*
>>               file.
>>
>>        PTRACE_MODE_ATTACH
>>               For  "write"  operations,  or  other operations that are
>>               more    dangerous,    such    as:    ptrace    attaching
>>               (PTRACE_ATTACH)    to   another   process   or   calling
>>               process_vm_writev(2).   (PTRACE_MODE_ATTACH  was  effec‐
>>               tively the default before Linux 2.6.27.)
>
> That was the intent when the distinction was introduced, but it doesn't
> appear to have been properly maintained, e.g. there is now a common
> helper lock_trace() that is used for
> /proc/pid/{stack,syscall,personality} but checks PTRACE_MODE_ATTACH, and
> PTRACE_MODE_ATTACH is also used in timerslack_ns_write/show().  Likely
> should review and make them consistent.  There was also some debate
> about proper handling of /proc/pid/fd.  Arguably that one might belong
> back in the _ATTACH camp.

Thanks for the background info.

>>        Since  Linux  4.5, the above access mode checks may be combined
>>        (ORed) with one of the following modifiers:
>>
>>        PTRACE_MODE_FSCREDS
>>               Use the caller's filesystem UID  and  GID  (see  creden‐
>>               tials(7)) or effective capabilities for LSM checks.
>>
>>        PTRACE_MODE_REALCREDS
>>               Use the caller's real UID and GID or permitted capabili‐
>>               ties for LSM checks.  This was effectively  the  default
>>               before Linux 4.5.
>>
>>        Because  combining  one of the credential modifiers with one of
>>        the aforementioned access modes is  typical,  some  macros  are
>>        defined in the kernel sources for the combinations:
>>
>>        PTRACE_MODE_READ_FSCREDS
>>               Defined as PTRACE_MODE_READ | PTRACE_MODE_FSCREDS.
>>
>>        PTRACE_MODE_READ_REALCREDS
>>               Defined as PTRACE_MODE_READ | PTRACE_MODE_REALCREDS.
>>
>>        PTRACE_MODE_ATTACH_FSCREDS
>>               Defined as PTRACE_MODE_ATTACH | PTRACE_MODE_FSCREDS.
>>
>>        PTRACE_MODE_ATTACH_REALCREDS
>>               Defined as PTRACE_MODE_ATTACH | PTRACE_MODE_REALCREDS.
>>
>>        One further modifier can be ORed with the access mode:
>>
>>        PTRACE_MODE_NOAUDIT (since Linux 3.3)
>>               Don't audit this access mode check.
>>
>> [I'd quite welcome some text to explain "auditing" here.]
>
> Some ptrace access mode checks, such as checks when reading
> /proc/pid/stat, merely cause the output to be filtered/sanitized rather
> than an error to be returned to the caller.  In these cases, accessing
> the file is not a security violation and there is no reason to generate
> a security audit record.  This modifier suppresses the generation of
> such an audit record for the particular access check.

Thanks, I've added that text to the man page more or less as you
gave it here.

Cheers,

Michael



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web