| 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: <0017835d-c672-02fe-dab8-d1b11c100c24@gmail.com>
Date: Tue, 28 Jun 2016 08:11:36 +0200
From: "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To: Jann Horn <jann@...jh.net>
Cc: mtk.manpages@...il.com, 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
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. 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?
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
Powered by blists - more mailing lists