From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751996AbcGaS6d (ORCPT ); Sun, 31 Jul 2016 14:58:33 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:58276 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750805AbcGaS6V (ORCPT ); Sun, 31 Jul 2016 14:58:21 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Mateusz Guzik Cc: Cyrill Gorcunov , Stanislav Kinsburskiy , peterz@infradead.org, mingo@redhat.com, mhocko@suse.com, keescook@chromium.org, linux-kernel@vger.kernel.org, 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, Richard Guy Briggs References: <20160712152940.24895.61315.stgit@localhost.localdomain> <8a863273-c571-63d6-c0c3-637dff5645a3@virtuozzo.com> <87y44pbmtc.fsf@x220.int.ebiederm.org> <20160725192242.GA26208@uranus> <87a8h58pac.fsf@x220.int.ebiederm.org> <20160726083445.GB26208@uranus> <87y44j6nib.fsf@x220.int.ebiederm.org> <20160730202821.7ojhciviocjfnw7p@mguzik> Date: Sun, 31 Jul 2016 13:45:09 -0500 In-Reply-To: <20160730202821.7ojhciviocjfnw7p@mguzik> (Mateusz Guzik's message of "Sat, 30 Jul 2016 22:28:22 +0200") Message-ID: <87vazlzlxm.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=1bTvwE-0006jN-81;;;mid=<87vazlzlxm.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+u+NdgcM2XdMzI43tnGbrK3F31MSs3Db8= 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.7 XMSubLong Long Subject * 0.0 TVD_RCVD_IP Message was received from an IP address * 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 * [sa04 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; sa04 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;Mateusz Guzik X-Spam-Relay-Country: X-Spam-Timing: total 1035 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 5 (0.5%), b_tie_ro: 3.6 (0.4%), parse: 3.5 (0.3%), extract_message_metadata: 3.6 (0.3%), get_uri_detail_list: 1.45 (0.1%), tests_pri_-1000: 4.3 (0.4%), tests_pri_-950: 1.24 (0.1%), tests_pri_-900: 1.02 (0.1%), tests_pri_-400: 26 (2.5%), check_bayes: 25 (2.4%), b_tokenize: 7 (0.7%), b_tok_get_all: 9 (0.9%), b_comp_prob: 2.4 (0.2%), b_tok_touch_all: 3.9 (0.4%), b_finish: 0.83 (0.1%), tests_pri_0: 972 (94.0%), check_dkim_signature: 0.56 (0.1%), check_dkim_adsp: 89 (8.6%), tests_pri_500: 6 (0.6%), 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 Mateusz Guzik writes: > On Sat, Jul 30, 2016 at 12:31:40PM -0500, Eric W. Biederman wrote: >> So what I am requesting is very simple. That the checks in >> prctl_set_mm_exe_file be tightened up to more closely approach what >> execve requires. Thus preserving the value of the /proc/[pid]/exe for >> the applications that want to use the exe link. >> >> Once the checks in prctl_set_mm_exe_file are tightened up please feel >> free to remove the one shot test. >> > > This is more fishy. > > First of all exe_file is used by the audit subsystem. So someone has to > ask audit people what is the significance (if any) of the field. > > All exe_file users but one use get_mm_exe_file and handle NULL > gracefully. > > Even with the current limit of changing the field once, the user can > cause a transient failure of get_mm_exe_file which can fail to increment > the refcount before it drops to 0. > > This transient failure can be used to get a NULL value stored in > ->exe_file during fork (in dup_mmap): > RCU_INIT_POINTER(mm->exe_file, get_mm_exe_file(oldmm)); > > The one place which is not using get_mm_exe_file to get to the pointer > is audit_exe_compare: > rcu_read_lock(); > exe_file = rcu_dereference(tsk->mm->exe_file); > ino = exe_file->f_inode->i_ino; > dev = exe_file->f_inode->i_sb->s_dev; > rcu_read_unlock(); > > This is buggy on 2 accounts: > 1. exe_file can be NULL > 2. rcu does not protect f_inode > > The issue is made worse with allowing arbitrary number changes. > > Modifying get_mm_exe_file to retry is trivial and in effect never return > NULL is trivial. With arbitrary number of changes allowed this may > require some cond_resched() or something. > > For comments I cc'ed Richard Guy Briggs, who is both an audit person and > the author of audit_exe_compare. That is fair. Keeping the existing users working is what needs to happen. At the same time we have an arbitrary number of possible changes with exec, but I guess that works differently because the mm is changed as well. So yes let's bug fix this piece of code and then we can see about relaxing constraints. Eric