From: ebiederm@xmission.com (Eric W. Biederman)
To: "Michael Kerrisk \(man-pages\)" <mtk.manpages@gmail.com>
Cc: Oleg Nesterov <oleg@redhat.com>, Jann Horn <jann@thejh.net>,
James Morris <jmorris@namei.org>,
linux-man <linux-man@vger.kernel.org>,
Stephen Smalley <sds@tycho.nsa.gov>,
lkml <linux-kernel@vger.kernel.org>,
Kees Cook <keescook@chromium.org>,
linux-security-module <linux-security-module@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>
Subject: Re: Documenting ptrace access mode checking
Date: Thu, 23 Jun 2016 13:56:39 -0500 [thread overview]
Message-ID: <871t3nka3c.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <f8069f83-f7b6-ee2c-5167-fa0d50732180@gmail.com> (Michael Kerrisk's message of "Thu, 23 Jun 2016 09:06:55 +0200")
"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
> Hi Oleg,
>
> On 06/22/2016 11:51 PM, Oleg Nesterov wrote:
>> On 06/21, Eric W. Biederman wrote:
>>>
>>> Adding Oleg just because he seems to do most of the ptrace related
>>> maintenance these days.
>>
>> so I have to admit that I never even tried to actually understand
>> ptrace_may_access ;)
>>
>>> 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.
>>
>> Personally I agree. I think "man ptrace" shouldn't not tell too much
>> about kernel internals.
>
> See my other replies on this topic. Somehow, we need a way of
> describing the behavior that user-space sees. I think it's
> inevitable that that means talking about what;s going on
> "under the hood".
>
> Regarding Eric's point that "we run the danger of people beginning
> to think they can depend upon bugs in the implementation": when it
> comes to breaking the ABI, the presence or absence of documentation
> doesn't save us on that point (Linus has a few times made his position
> wrt to documentation clear).
Which are interesting in this respect as a bug in the implementation
that is a security issue can and will be changed, even if userspace
breaks. Breaking userspace is not desirable but when there is no other
reasonable choice it will happen.
Eric
next prev parent reply other threads:[~2016-06-23 19:09 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-21 9:41 Documenting ptrace access mode checking Michael Kerrisk (man-pages)
2016-06-21 19:55 ` Eric W. Biederman
2016-06-21 20:29 ` Kees Cook
2016-06-21 20:58 ` Eric W. Biederman
2016-06-22 19:20 ` Michael Kerrisk (man-pages)
2016-06-22 19:20 ` Michael Kerrisk (man-pages)
2016-06-23 19:04 ` Eric W. Biederman
2016-06-24 9:57 ` Michael Kerrisk (man-pages)
2016-06-22 21:51 ` Oleg Nesterov
2016-06-23 7:06 ` Michael Kerrisk (man-pages)
2016-06-23 18:56 ` Eric W. Biederman [this message]
2016-06-24 8:18 ` Michael Kerrisk (man-pages)
2016-06-21 20:55 ` Jann Horn
2016-06-22 19:21 ` Michael Kerrisk (man-pages)
2016-06-22 21:11 ` Kees Cook
2016-06-23 7:02 ` Michael Kerrisk (man-pages)
2016-06-24 8:40 ` Michael Kerrisk (man-pages)
2016-06-24 15:18 ` Casey Schaufler
2016-06-24 20:07 ` Kees Cook
2016-06-25 7:21 ` Michael Kerrisk (man-pages)
2016-06-22 22:44 ` Jann Horn
2016-06-23 7:42 ` Michael Kerrisk (man-pages)
2016-06-24 6:35 ` Jann Horn
2016-06-23 18:05 ` Stephen Smalley
2016-06-24 8:33 ` Michael Kerrisk (man-pages)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871t3nka3c.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=jann@thejh.net \
--cc=jmorris@namei.org \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=oleg@redhat.com \
--cc=sds@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).