Received: by 10.192.165.148 with SMTP id m20csp723795imm; Wed, 2 May 2018 07:50:25 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqCpKBTrQ4IdY+jykxgK/bJp30AGtUZEbt3E7J/hbTT9THh9h7oZrEitJWaEDaM0Dw9IESb X-Received: by 2002:a63:6b43:: with SMTP id g64-v6mr9007391pgc.337.1525272625104; Wed, 02 May 2018 07:50:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525272625; cv=none; d=google.com; s=arc-20160816; b=cPPzTdZjUtbfZBySqwloaZ+KVrfIpWR07EQVvNLuDnSS+Gr3cmReaFzWMccfLGqcNu EBtSi7u2b8uLzp31cQ7r6FwOuU3GDzo7X6xYeNLSVVMvid3AbtY6w7kIqo1uPyz/sYO5 qo1gt/s+Y2iCUTaYpZ+RuH+tVKAuBFi07TjKqqrT+hL+8m7jaEv2lvGFdA67FgCl1iKV /yX7Fgf0yUUNv6oHyErJUMFMUS7zRO36/Ivq5wjSN9uZ6cApDH9EFS9RMNkQNsIs1LHn whTIBGk2Dhd5nvh7+J9JfflY+pnPT9xPm0FojDlMjm07lQSi+2uDayqSD4XYL2Vehqpp Jasw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:subject:mime-version:user-agent :message-id:in-reply-to:date:references:cc:to:from :arc-authentication-results; bh=BXwHMsW3X+SrhKTfGLLIQGA4RLP3EhT912CyQdZwpYM=; b=KZ0UseuolklUCdwpEViQnV3jrMaNEqzLlwYoD1MfPNkCeq3oRB+ZUxz6uXGtC6vXzq ItRVgWSQzGUxtc0wtkg53HM65rI7p+xSrb2QqAJ4/cIZrRSCsY2rxxos6FTzNNfclRQ3 LaFyf0Djq3dMyrDrjyTdZlKhZdxKPKorWqmPoA2Wpwld2gY1C9Hjl3mM1GOJhncfLiXj jhdAOKb9wRcq+Xxu9z8EZ/kyksZWsBQ0fSLINAaT237Vpe7DpY7vB2ExrvzD00lPgd/U U5jS6TSd8NeL1oqeWy+AHk8Q6QJ9esJ7bMHln2iVmvKQH1s6IS1kpJho7TGkTe6H/csn xATA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j21-v6si9363816pgn.334.2018.05.02.07.50.11; Wed, 02 May 2018 07:50:25 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751713AbeEBOta (ORCPT + 99 others); Wed, 2 May 2018 10:49:30 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:53450 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751652AbeEBOt1 (ORCPT ); Wed, 2 May 2018 10:49:27 -0400 Received: from in01.mta.xmission.com ([166.70.13.51]) by out03.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1fDt3F-0006se-9m; Wed, 02 May 2018 08:48:15 -0600 Received: from [97.119.174.25] (helo=x220.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1fDt2P-0001V2-IZ; Wed, 02 May 2018 08:47:43 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Mimi Zohar Cc: David Howells , Matthew Garrett , linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org References: <1523572911-16363-1-git-send-email-zohar@linux.vnet.ibm.com> <1523572911-16363-3-git-send-email-zohar@linux.vnet.ibm.com> Date: Wed, 02 May 2018 09:45:30 -0500 In-Reply-To: <1523572911-16363-3-git-send-email-zohar@linux.vnet.ibm.com> (Mimi Zohar's message of "Thu, 12 Apr 2018 18:41:50 -0400") Message-ID: <87h8nqglpx.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1fDt2P-0001V2-IZ;;;mid=<87h8nqglpx.fsf@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=97.119.174.25;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19HUl1dxhN65w7xXBUwMNRlsYBVIPVmL6E= X-SA-Exim-Connect-IP: 97.119.174.25 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa05.xmission.com X-Spam-Level: ** X-Spam-Status: No, score=2.4 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,T_TM2_M_HEADER_IN_MSG,T_TooManySym_01,T_XMDrugObfuBody_08, XMNoVowels,XMSolicitRefs_0 autolearn=disabled version=3.4.1 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 1.5 XMNoVowels Alpha-numberic number with no vowels * 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 * [sa05 1397; Body=1 Fuz1=1 Fuz2=1] * 0.1 XMSolicitRefs_0 Weightloss drug * 0.0 T_TooManySym_01 4+ unique symbols in subject * 1.0 T_XMDrugObfuBody_08 obfuscated drug references X-Spam-DCC: XMission; sa05 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;Mimi Zohar X-Spam-Relay-Country: X-Spam-Timing: total 2220 ms - load_scoreonly_sql: 0.06 (0.0%), signal_user_changed: 3.8 (0.2%), b_tie_ro: 2.5 (0.1%), parse: 1.51 (0.1%), extract_message_metadata: 6 (0.2%), get_uri_detail_list: 2.5 (0.1%), tests_pri_-1000: 6 (0.3%), tests_pri_-950: 1.95 (0.1%), tests_pri_-900: 1.59 (0.1%), tests_pri_-400: 23 (1.0%), check_bayes: 21 (1.0%), b_tokenize: 6 (0.3%), b_tok_get_all: 7 (0.3%), b_comp_prob: 2.1 (0.1%), b_tok_touch_all: 3.3 (0.1%), b_finish: 0.59 (0.0%), tests_pri_0: 2160 (97.3%), check_dkim_signature: 0.50 (0.0%), check_dkim_adsp: 2006 (90.3%), tests_pri_500: 4.0 (0.2%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH 2/3] kexec: call LSM hook for kexec_load syscall 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Mimi Zohar writes: > Allow LSMs and IMA to differentiate between the kexec_load and > kexec_file_load syscalls by adding an "unnecessary" call to > security_kernel_read_file() in kexec_load. This would be similar to the > existing init_module syscall calling security_kernel_read_file(). Given the reasonable desire to load a policy that ensures everything has a signature I don't have fundamental objections. security_kernel_read_file as a hook seems an odd choice. At the very least it has a bad name because there is no file reading going on here. I am concerned that I don't see CONFIG_KEXEC_VERIFY_SIG being tested anywhere. Which means I could have a kernel compiled without that and I would be allowed to use kexec_file_load without signature checking. While kexec_load would be denied. Am I missing something here? Eric > Signed-off-by: Mimi Zohar > --- > kernel/kexec.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/kernel/kexec.c b/kernel/kexec.c > index aed8fb2564b3..d1386cfc6796 100644 > --- a/kernel/kexec.c > +++ b/kernel/kexec.c > @@ -11,6 +11,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -195,11 +196,21 @@ static int do_kexec_load(unsigned long entry, unsigned long nr_segments, > static inline int kexec_load_check(unsigned long nr_segments, > unsigned long flags) > { > + int result; > + > /* We only trust the superuser with rebooting the system. */ > if (!capable(CAP_SYS_BOOT) || kexec_load_disabled) > return -EPERM; > > /* > + * Allow LSMs and IMA to differentiate between kexec_load and > + * kexec_file_load syscalls. > + */ > + result = security_kernel_read_file(NULL, READING_KEXEC_IMAGE); > + if (result < 0) > + return result; > + > + /* > * Verify we have a legal set of flags > * This leaves us room for future extensions. > */