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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 21 Jun 2016 15:58:39 -0500
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Kees Cook <keescook@...omium.org>
Cc:	"Michael Kerrisk \(man-pages\)" <mtk.manpages@...il.com>,
	Jann Horn <jann@...jh.net>, James Morris <jmorris@...ei.org>,
	linux-man <linux-man@...r.kernel.org>,
	Stephen Smalley <sds@...ho.nsa.gov>,
	lkml <linux-kernel@...r.kernel.org>,
	linux-security-module <linux-security-module@...r.kernel.org>,
	Linux API <linux-api@...r.kernel.org>,
	Oleg Nesterov <oleg@...hat.com>
Subject: Re: Documenting ptrace access mode checking

Kees Cook <keescook@...omium.org> writes:

> On Tue, Jun 21, 2016 at 12:55 PM, Eric W. Biederman
> <ebiederm@...ssion.com> wrote:
>
>> "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com> writes:
>>
>>>        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.
>>
>> This test only exsits because the LSMs historically and I suspect
>> continue to be broken and deny a process the ability to ptrace itself.
>
> Well, it's not that the LSMs are broken, it's that self-inspection is
> a short-circuited "allow". The LSMs aren't involved.

Long ago and far away.  I modified /proc/self/something to use the same
permissions as ptrace.  This broken everyone's selinux setups.  So the
short circuit was added.

Or in short the LSMs aren't involved because they got it wrong.

If the selinux breakage was not in the selinux rules that are loaded from
userspace but in the kernel module that short circuit check would have
been confined to selinux.

I have had an occasional thought and the occassional discussion about
removing that check and just fixing the LSMs but at this point I don't
think anyone cares enough to make that change.

Eric