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


Groups > linux.kernel > #1430072

Re: Documenting ptrace access mode checking

From ebiederm@xmission.com (Eric W. Biederman)
Newsgroups linux.kernel
Subject Re: Documenting ptrace access mode checking
Date 2016-06-23 21:20 +0200
Message-ID <rNikp-64A-19@gated-at.bofh.it> (permalink)
References <rMqtI-3ZE-17@gated-at.bofh.it> <rMA9H-22L-3@gated-at.bofh.it> <rMW0x-7AM-7@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:

> Hi Eric,
>
> On 06/21/2016 09:55 PM, Eric W. Biederman wrote:
>> Hmm.
>>
>> When I gave this level of detail about the user namespace permission
>> checks you gave me some flack, because it was not particularly
>> comprehensible to the end users.  I think you deserve the same feedback.
>>
>> How do we say this in a way that does not describes a useful way to
>> think about it.  I read this and I know a lot of what is going on and my
>> mind goes numb.
>>
>> How about something like this:
>>
>>    If the callers uid and gid are the same as a processes uids and gids
>>    and the processes is configured to allow core dumps (aka it was never
>>    setuid or setgid) then the caller is allowed to ptrace a process.
>>
>>    Otherwise the caller must have CAP_SYS_PTRACE.
>>
>>    Linux security modules impose additional restrictions.
>>
>>    For consistency access to various process attributes are guarded with
>>    the same security checks as the ptrace system call itself.  As they are
>>    all methods to get information about a process.
>>
>> We certainly need something that gives a high level view so people
>> reading the man page can know what to expect.   If you get down into the
>> weeds we run the danger of people beginning to think they can depend
>> upon bugs in the implementation.
>
> Thanks for the feedback, but I think more detail is required than you
> suggest. (And I added all of that detail somewhat reluctantly.)
> See my other replies for my rationale.

What I saw badly missing from your description is not the level of
detail but bring things into a form that ordinary mortals can
understand.

For an explanation to be clear I think we very much need the high level
overview first.  Then we can expand that description with the very
detailed view.

I very much think we need to describe things in such a way that people
understand the principles behind the permission checks, and not just
have the documentation echo the code, so that people can know what weird
things LSMs like yama are likely to do, and how these checks are likely
to evolve in the future.

Because one thing is clear to me.  The evolution of these details is
clearly not done, and will continue to change in the future.

Eric

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web