From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754353AbcGLRF5 (ORCPT ); Tue, 12 Jul 2016 13:05:57 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:43315 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750850AbcGLRFz (ORCPT ); Tue, 12 Jul 2016 13:05:55 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Cyrill Gorcunov Cc: Stanislav Kinsburskiy , peterz@infradead.org, mingo@redhat.com, mhocko@suse.com, keescook@chromium.org, linux-kernel@vger.kernel.org, mguzik@redhat.com, bsegall@google.com, john.stultz@linaro.org, oleg@redhat.com, matthltc@us.ibm.com, akpm@linux-foundation.org, luto@amacapital.net, vbabka@suse.cz, xemul@virtuozzo.com References: <20160712152940.24895.61315.stgit@localhost.localdomain> <20160712164800.GD3661@uranus.lan> Date: Tue, 12 Jul 2016 11:52:09 -0500 In-Reply-To: <20160712164800.GD3661@uranus.lan> (Cyrill Gorcunov's message of "Tue, 12 Jul 2016 19:48:00 +0300") Message-ID: <87inwa2406.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1bN176-0002uo-LP;;;mid=<87inwa2406.fsf@x220.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=67.3.204.119;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/dVYgruV5jUg8aqCpehmfSFcTGGeZmuOg= X-SA-Exim-Connect-IP: 67.3.204.119 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.7 XMSubLong Long Subject * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] * 1.0 XMSubMetaSx_00 1+ Sexy Words * 1.2 XMSubMetaSxObfu_02 Obfuscated Sexy AdVerb X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;Cyrill Gorcunov X-Spam-Relay-Country: X-Spam-Timing: total 807 ms - load_scoreonly_sql: 0.06 (0.0%), signal_user_changed: 3.3 (0.4%), b_tie_ro: 2.2 (0.3%), parse: 0.71 (0.1%), extract_message_metadata: 21 (2.6%), get_uri_detail_list: 1.90 (0.2%), tests_pri_-1000: 11 (1.4%), tests_pri_-950: 1.76 (0.2%), tests_pri_-900: 1.57 (0.2%), tests_pri_-400: 25 (3.1%), check_bayes: 23 (2.9%), b_tokenize: 7 (0.9%), b_tok_get_all: 8 (1.0%), b_comp_prob: 2.4 (0.3%), b_tok_touch_all: 3.2 (0.4%), b_finish: 0.65 (0.1%), tests_pri_0: 461 (57.1%), check_dkim_signature: 0.75 (0.1%), check_dkim_adsp: 3.7 (0.5%), tests_pri_500: 278 (34.4%), poll_dns_idle: 272 (33.7%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH] prctl: remove one-shot limitation for changing exe link X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Cyrill Gorcunov 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 > > 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 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