linux-kernel - Re: [PATCH] prctl: remove one-shot limitation for changing exe link

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: <87inwa2406.fsf@x220.int.ebiederm.org>
Date:	Tue, 12 Jul 2016 11:52:09 -0500
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Cyrill Gorcunov <gorcunov@...il.com>
Cc:	Stanislav Kinsburskiy <skinsbursky@...tuozzo.com>,
	peterz@...radead.org, mingo@...hat.com, mhocko@...e.com,
	keescook@...omium.org, linux-kernel@...r.kernel.org,
	mguzik@...hat.com, bsegall@...gle.com, john.stultz@...aro.org,
	oleg@...hat.com, matthltc@...ibm.com, akpm@...ux-foundation.org,
	luto@...capital.net, vbabka@...e.cz, xemul@...tuozzo.com
Subject: Re: [PATCH] prctl: remove one-shot limitation for changing exe link

Cyrill Gorcunov <gorcunov@...il.com> writes:

> On Tue, Jul 12, 2016 at 07:30:29PM +0400, Stanislav Kinsburskiy wrote:
>> This limitation came with the reason to remove "another
>> way for malicious code to obscure a compromised program and
>> masquerade as a benign process" by allowing "security-concious program can use
>> this prctl once during its early initialization to ensure the prctl cannot
>> later be abused for this purpose":
>> 
>> http://marc.info/?l=linux-kernel&m=133160684517468&w=2
>> 
>> But the way how the feature can be used is the following:
>> 
>> 1) Attach to process via ptrace (protected by CAP_SYS_PTRACE)
>> 2) Unmap all the process file mappings, related to "exe" file.
>> 3) Change exe link (protected by CAP_SYS_RESOURCE).
>> 
>> IOW, some other process already has an access to process internals (and thus
>> it's already compromised), and can inject fork and use the child of the
>> compromised program to masquerade.
>> Which means this limitation doesn't solve the problem it was aimed to.
>> 
>> While removing this limitation allow to replace files from underneath of a
>> running process as many times as required. One of the use cases is network
>> file systems migration (NFS, to be precise) by CRIU.
>> 
>> NFS mount can't be mounted on restore stage because network is locked.
>> To overcome this limitation, another file system (FUSE-based) is used. Then
>> opened files replaced by the proper ones NFS is remounted.
>> Thus exe link replace has to be done twice: first on restore stage and second
>> - when actual NFS was remounted.
>> 
>> Signed-off-by: Stanislav Kinsburskiy <skinsbursky@...tuozzo.com>
>
> Persistent exe-link doesn't guarantee anything if you have rights to ptrace
> task and inject own code into (from security POV). So lets rip it out.
>
> Acked-by: Cyrill Gorcunov <gorcunov@...nvz.org>

I believe the original concern was someone injecting a code into a
process and playing silly buggers with the exe link.  Someone who does
not have ptrace capability.

It is completely not ok to change this until someone goes back to the
original conversation and looks at the original threat model, and
refutes it.

Eric