linux-kernel - Re: Review of ptrace Yama ptrace

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]

Message-ID: <20160625143006.GA24730@pc.thejh.net>
Date:	Sat, 25 Jun 2016 16:30:07 +0200
From:	Jann Horn <jann@...jh.net>
To:	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
Cc:	Kees Cook <keescook@...omium.org>,
	Linux API <linux-api@...r.kernel.org>,
	linux-man <linux-man@...r.kernel.org>,
	linux-security-module <linux-security-module@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Casey Schaufler <casey@...aufler-ca.com>,
	James Morris <jmorris@...ei.org>
Subject: Re: Review of ptrace Yama ptrace_scope description

On Sat, Jun 25, 2016 at 09:30:43AM +0200, Michael Kerrisk (man-pages) wrote:
> Hi Kees,
> 
> So, last year, I added some documentation to ptrace(2) to describe
> the Yama ptrace_scope file. I don't think I asked you for review
> at the time, but in the light of other changes to the ptrace(2)
> page, it occurred to me that it might be a good idea to ask you
> to check the text below to see if anything is missing or could be
> improved. Might you have a moment for that?
> 
>    /proc/sys/kernel/yama/ptrace_scope
>        On systems with the Yama Linux Security Module (LSM)  installed
>        (i.e.,  the  kernel  was configured with CONFIG_SECURITY_YAMA),
>        the /proc/sys/kernel/yama/ptrace_scope  file  (available  since
>        Linux  3.4)  can  be  used  to  restrict the ability to trace a
>        process with ptrace(2) (and thus also the ability to use  tools
>        such  as  strace(1) and gdb(1)).  The goal of such restrictions
>        is to prevent attack escalation whereby a  compromised  process
>        can  ptrace-attach  to  other  sensitive processes (e.g., a GPG
>        agent or an SSH session) owned by the user  in  order  to  gain
>        additional credentials and thus expand the scope of the attack.
> 
>        More precisely, the Yama LSM limits two types of operations:
> 
>        *  Any   operation   that   performs   a   ptrace  access  mode
>           PTRACE_MODE_ATTACH     check—for      example,      ptrace()
>           PTRACE_ATTACH.   (See the "Ptrace access mode checking" dis‐
>           cussion above.)
> 
>        *  ptrace() PTRACE_TRACEME.
> 
>        A process that has the CAP_SYS_PTRACE capability can update the
>        /proc/sys/kernel/yama/ptrace_scope file with one of the follow‐
>        ing values:
> 
>        0 ("classic ptrace permissions")
>               No additional restrictions on  operations  that  perform
>               PTRACE_MODE_ATTACH  checks  (beyond those imposed by the
>               commoncap and other LSMs).
> 
>               The use of PTRACE_TRACEME is unchanged.
> 
>        1 ("restricted ptrace") [default value]
>               When   performing   an   operation   that   requires   a
>               PTRACE_MODE_ATTACH  check, the calling process must have
>               a predefined relationship with the target  process.   By
>               default,  the predefined relationship is that the target
>               process must be a child of the caller.
> 
>               A target process can employ the prctl(2)  PR_SET_PTRACER
>               operation  to declare a different PID that is allowed to
>               perform PTRACE_MODE_ATTACH  operations  on  the  target.
>               See   the   kernel   source   file   Documentation/secu‐
>               rity/Yama.txt for further details.
> 
>               The use of PTRACE_TRACEME is unchanged.

(namespaced) CAP_SYS_PTRACE is also sufficient here.


Both here and in the "admin-only attach" case, it is IMO important to
note that creating a user namespace effectively removes the Yama
protection because the owner of a namespace, when accessing its
contents from outside, is relatively capable.

This means that when a process tries to use namespaces to sandbox
itself, it inadvertently makes itself more accessible.

(This could probably be worked around in the kernel, but such a
workaround would likely not be default, but rather opt-in via a new
flag for clone() and unshare() or so.)


>        2 ("admin-only attach")
>               Only processes with the  CAP_SYS_PTRACE  capability  may
>               perform  PTRACE_MODE_ATTACH operations or trace children
>               that employ PTRACE_TRACEME.

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