| 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
| ||
|
Message-ID: <20160628205007.GA1419@pc.thejh.net>
Date: Tue, 28 Jun 2016 22:50:07 +0200
From: Jann Horn <jann@...jh.net>
To: "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>,
Kees Cook <keescook@...omium.org>
Cc: 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 Tue, Jun 28, 2016 at 08:11:36AM +0200, Michael Kerrisk (man-pages) wrote:
> Hi Jann,
>
> On 06/25/2016 04:30 PM, Jann Horn wrote:
> >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.)
>
> Tanks for catching this!
>
> So I've made that section of text:
>
> A process that has the CAP_SYS_PTRACE capability can update the
> /proc/sys/kernel/yama/ptrace_scope file with one of the following
> values:
>
> 0 ("classic ptrace permissions")
> No additional restrictions on operations that perform
> PTRACE_MODE_ATTACH checks (beyond those imposed by the com‐
> moncap 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 either
> have the CAP_SYS_PTRACE capability in the user namespace of
> the target process or it have a predefined relationship
> with the target process.
Nit: The grammar in this sentence seems wrong to me.
s/or it have/or it must have/?
> By default, the predefined rela‐
> tionship 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/security/Yama.txt for
> further details.
>
> The use of PTRACE_TRACEME is unchanged.
>
> 2 ("admin-only attach")
> Only processes with the CAP_SYS_PTRACE capability in the
> user namespace of the target process may perform
> PTRACE_MODE_ATTACH operations or trace children that employ
> PTRACE_TRACEME.
>
> 3 ("no attach")
> No process may perform PTRACE_MODE_ATTACH operations or
> trace children that employ PTRACE_TRACEME.
>
> Once this value has been written to the file, it cannot be
> changed.
>
> With respect to values 1 and 2, note that creating a user names‐
> pace effectively removes the Yama protection, because the owner of
> a namespace, when accessing its members from outside, has
> CAP_SYS_PTRACE within the namespace. This means that when a
> process tries to use namespaces to sandbox itself, it inadver‐
> tently weakens the protections offered by the Yama LSM.
>
>
> Okay?
Sounds good to me. Kees?
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists