Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753273AbaDYTFm (ORCPT ); Fri, 25 Apr 2014 15:05:42 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:37137 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752200AbaDYTF2 (ORCPT ); Fri, 25 Apr 2014 15:05:28 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Oleg Nesterov Cc: Dmitry Kasatkin , linux-security-module , john.johansen@canonical.com, Mimi Zohar , James Morris , viro@ZenIV.linux.org.uk, Linux Kernel Mailing List , kernel-team@lists.ubuntu.com References: <535A5C78.1070901@samsung.com> <535A75C1.3050901@samsung.com> <20140425182310.GA9128@redhat.com> Date: Fri, 25 Apr 2014 12:04:50 -0700 In-Reply-To: <20140425182310.GA9128@redhat.com> (Oleg Nesterov's message of "Fri, 25 Apr 2014 20:23:10 +0200") Message-ID: <87sip15iy5.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX19JsdgwlFdBIIQL5xDma1yJKpijEdms6NQ= X-SA-Exim-Connect-IP: 98.234.51.111 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 T_TM2_M_HEADER_IN_MSG BODY: T_TM2_M_HEADER_IN_MSG * 1.2 LotsOfNums_01 BODY: Lots of long strings of numbers * 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 T_XMDrugObfuBody_12 obfuscated drug references X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;Oleg Nesterov X-Spam-Relay-Country: Subject: Re: Kernel panic at Ubuntu: IMA + Apparmor X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 14 Nov 2012 13:58:17 -0700) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Oleg Nesterov writes: > On 04/25, Dmitry Kasatkin wrote: >> >> On 25/04/14 16:00, Dmitry Kasatkin wrote: >> > Hello, >> > >> > I discovered a kernel panic on system running Ubuntu when IMA is enabled. >> > It happens on reboot. >> > >> > ---------------------- >> > [ 106.750100] NSPROXY is NULL: error.log (/var/log/mysql/error.log) >> > [ 106.750167] BUG: unable to handle kernel NULL pointer dereference at >> > 0000000000000018 >> > [ 106.750221] IP: [] our_mnt+0x1a/0x30 > ... >> > [ 106.751149] Call Trace: >> > [ 106.751172] [] ? aa_path_name+0x2ab/0x430 >> > [ 106.751199] [] ? sched_clock+0x9/0x10 >> > [ 106.751225] [] aa_path_perm+0x7d/0x170 >> > [ 106.751250] [] ? native_sched_clock+0x15/0x80 >> > [ 106.751276] [] aa_file_perm+0x33/0x40 >> > [ 106.751301] [] common_file_perm+0x8e/0xb0 >> > [ 106.751327] [] apparmor_file_permission+0x18/0x20 >> > [ 106.751355] [] security_file_permission+0x23/0xa0 >> > [ 106.751382] [] rw_verify_area+0x52/0xe0 >> > [ 106.751407] [] vfs_read+0x6d/0x170 >> > [ 106.751432] [] kernel_read+0x41/0x60 >> > [ 106.751457] [] ima_calc_file_hash+0x225/0x280 >> > [ 106.751483] [] ? ima_calc_file_hash+0x32/0x280 >> > [ 106.751509] [] ima_collect_measurement+0x9d/0x160 >> > [ 106.751536] [] ? trace_hardirqs_on+0xd/0x10 >> > [ 106.751562] [] ? ima_file_free+0x6c/0xd0 >> > [ 106.751587] [] ima_update_xattr+0x34/0x60 >> > [ 106.751612] [] ima_file_free+0xc0/0xd0 >> > [ 106.751637] [] __fput+0xd5/0x300 > > fantastic ;) > >> > [ 106.751662] [] ____fput+0xe/0x10 >> > [ 106.751687] [] task_work_run+0xc4/0xe0 >> > [ 106.751712] [] do_exit+0x2bd/0xa90 >> > [ 106.751738] [] ? retint_swapgs+0x13/0x1b >> > [ 106.751763] [] do_group_exit+0x4c/0xc0 > ... >> It seems the problem is the order of functions in do_exit >> >> do_exit() >> { >> ... >> exit_task_namespaces(tsk); >> exit_task_work(tsk); > > Yes. > > Eric, this makes me think again that we should do exit_task_namespaces() > after exit_task_work(). We already discussed this before, but this looks > like another indication this change makes sense. I know you mentioned something about that. I haven't actually had much time to think about it. > The problem with fput() from free_nsproxy() was hopefully also fixed by > e7b2c4069252. The main motivation for "move" was "outside of exit_notify". > Even if we fix the paths above task_work_add() can have another user which > wants ->nsproxy. > > What do you think? I am scratching my head. Delayed work that depends on current sort of blows my mind. As I read this it is coming from __fput. Hmm. So I think the blinkered thing is having a security_file_permission inside of kernel_read. That is utter nonsense. At least for a kernel_read we are doing from ima. apparmor should not be trying to limit ima. Show me a legitimate bug caused by the ordering and we can discuss reordering. Looking at kernel_read it is used elsewhere by the binfmt routines, and doing permissions checks there on the part of the user that is doing exec seems appropriate. So I think the deep bug here is ima is using kernel_read which is inappropriate for what it is trying to do. Permission checks on an integrity mechanism? Even if we ignore insane the security_file_permission in rw_verify_area we still have mandatory locks that could cause this to fail. Which looks like an evil user could bypass ima by simply setting a mandatory lock on a file and not letting anyone else read it. Which makes vfs_read and thus kernel_read wildly inappropriate for what ima is trying to do. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/