From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from out03.mta.xmission.com ([166.70.13.233]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1fEGWj-0000nu-F0 for kexec@lists.infradead.org; Thu, 03 May 2018 15:52:14 +0000 From: ebiederm@xmission.com (Eric W. Biederman) References: <1523572911-16363-1-git-send-email-zohar@linux.vnet.ibm.com> <1523572911-16363-3-git-send-email-zohar@linux.vnet.ibm.com> <87h8nqglpx.fsf@xmission.com> <1525275904.5669.308.camel@linux.vnet.ibm.com> Date: Thu, 03 May 2018 10:51:38 -0500 In-Reply-To: <1525275904.5669.308.camel@linux.vnet.ibm.com> (Mimi Zohar's message of "Wed, 02 May 2018 11:45:04 -0400") Message-ID: <87h8nospo5.fsf@xmission.com> MIME-Version: 1.0 Subject: Re: [PATCH 2/3] kexec: call LSM hook for kexec_load syscall List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Mimi Zohar Cc: kexec@lists.infradead.org, linux-kernel@vger.kernel.org, Matthew Garrett , David Howells , linux-security-module@vger.kernel.org, linux-integrity@vger.kernel.org TWltaSBab2hhciA8em9oYXJAbGludXgudm5ldC5pYm0uY29tPiB3cml0ZXM6Cgo+IE9uIFdlZCwg MjAxOC0wNS0wMiBhdCAwOTo0NSAtMDUwMCwgRXJpYyBXLiBCaWVkZXJtYW4gd3JvdGU6Cj4+IE1p bWkgWm9oYXIgPHpvaGFyQGxpbnV4LnZuZXQuaWJtLmNvbT4gd3JpdGVzOgo+PiAKPj4gPiBBbGxv dyBMU01zIGFuZCBJTUEgdG8gZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIHRoZSBrZXhlY19sb2FkIGFu ZAo+PiA+IGtleGVjX2ZpbGVfbG9hZCBzeXNjYWxscyBieSBhZGRpbmcgYW4gInVubmVjZXNzYXJ5 IiBjYWxsIHRvCj4+ID4gc2VjdXJpdHlfa2VybmVsX3JlYWRfZmlsZSgpIGluIGtleGVjX2xvYWQu ICBUaGlzIHdvdWxkIGJlIHNpbWlsYXIgdG8gdGhlCj4+ID4gZXhpc3RpbmcgaW5pdF9tb2R1bGUg c3lzY2FsbCBjYWxsaW5nIHNlY3VyaXR5X2tlcm5lbF9yZWFkX2ZpbGUoKS4KPj4gCj4+IEdpdmVu IHRoZSByZWFzb25hYmxlIGRlc2lyZSB0byBsb2FkIGEgcG9saWN5IHRoYXQgZW5zdXJlcyBldmVy eXRoaW5nCj4+IGhhcyBhIHNpZ25hdHVyZSBJIGRvbid0IGhhdmUgZnVuZGFtZW50YWwgb2JqZWN0 aW9ucy4KPj4gCj4+IHNlY3VyaXR5X2tlcm5lbF9yZWFkX2ZpbGUgYXMgYSBob29rIHNlZW1zIGFu IG9kZCBjaG9pY2UuICBBdCB0aGUgdmVyeQo+PiBsZWFzdCBpdCBoYXMgYSBiYWQgbmFtZSBiZWNh dXNlIHRoZXJlIGlzIG5vIGZpbGUgcmVhZGluZyBnb2luZyBvbiBoZXJlLgo+PiAKPj4gSSBhbSBj b25jZXJuZWQgdGhhdCBJIGRvbid0IHNlZSBDT05GSUdfS0VYRUNfVkVSSUZZX1NJRyBiZWluZyB0 ZXN0ZWQKPj4gYW55d2hlcmUuICBXaGljaCBtZWFucyBJIGNvdWxkIGhhdmUgYSBrZXJuZWwgY29t cGlsZWQgd2l0aG91dCB0aGF0IGFuZCBJCj4+IHdvdWxkIGJlIGFsbG93ZWQgdG8gdXNlIGtleGVj X2ZpbGVfbG9hZCB3aXRob3V0IHNpZ25hdHVyZSBjaGVja2luZy4KPj4gV2hpbGUga2V4ZWNfbG9h ZCB3b3VsZCBiZSBkZW5pZWQuCj4+IAo+PiBBbSBJIG1pc3Npbmcgc29tZXRoaW5nIGhlcmU/Cj4K PiBUaGUga2V4ZWNfZmlsZV9sb2FkKCkgY2FsbHMga2VybmVsX3JlYWRfZmlsZV9mcm9tX2ZkKCks IHdoaWNoIGluIHR1cm4KPiBjYWxscyBzZWN1cml0eV9rZXJuZWxfcmVhZF9maWxlKCkuIMKgU28g a2V4ZWNfZmlsZV9sb2FkIGFuZCBrZXhlY19sb2FkCj4gc3lzY2FsbCB3b3VsZCBiZSB1c2luZyB0 aGUgc2FtZSBtZXRob2QgZm9yIGVuZm9yY2luZyBzaWduYXR1cmUKPiB2ZXJpZmljYXRpb24uCgpI YXZpbmcgbG9va2VkIGF0IHlvdXIgcGF0Y2hlcyBhbmQgdGhlIGtlcm5lbCBhIGxpdHRsZSBtb3Jl IEkgdGhpbmsKdGhpcyBzaG91bGQgYmUgYSBzZXBhcmF0ZSBzZWN1cml0eSBob29rIHRoYXQgZG9l cyBub3QgdGFrZSBhIGZpbGUKcGFyYW1ldGVyLgoKUmlnaHQgbm93IGV2ZXJ5IG90aGVyIHNlY3Vy aXR5IG1vZHVsZSBhc3N1bWVzICFmaWxlIGlzIGluaXRfbW9kdWxlLgpTbyBJIHRoaW5rIHRoaXMg Y2hhbmdlIGhhcyB0aGUgcG90ZW50aWFsIHRvIGNvbmZ1c2Ugb3RoZXIgc2VjdXJpdHkKbW9kdWxl cywgd2l0aCB0aGUgcmVzdWx0IG9mIHVuaW50ZW5kZWQgcG9saWN5IGJlaW5nIGFwcGxpZWQuCgpT byBqdXN0IGZvciBnb29kIHNlY3VyaXR5IG1vZHVsZSBoeWdlaW5lIEkgdGhpbmsgdGhpcyBuZWVk cyBhIGRlZGljYXRlZAprZXhlY19sb2FkIHNlY3VyaXR5IGhvb2suCgoKPiBUaGlzIGlzIGluZGVw ZW5kZW50IG9mIHRoZSBhcmNoaXRlY3R1cmUgc3BlY2lmaWMgbWV0aG9kIGZvciB2ZXJpZnlpbmcK PiBzaWduYXR1cmVzLiDCoFRoZSBjb29yZGluYXRpb24gYmV0d2VlbiB0aGVzZSB0d28gbWV0aG9k cyB3YXMgaW5jbHVkZWQKPiBpbiB0aGUgbG9ja2Rvd24gcGF0Y2ggc2V0LCBidXQgaXMgYmVpbmcg cmVtb3ZlZCwgYXMgd2VsbCB0aGUgZ2F0aW5nIG9mCj4ga2V4ZWNfbG9hZCBzeXNjYWxsLiDCoElu c3RlYWQgb2YgYmVpbmcgYmFzZWQgb24gdGhlIGxvY2tkb3duIGZsYWcsIEkKPiBhc3N1bWUgdGhl IGNvb3JkaW5hdGlvbiBiZXR3ZWVuIHRoZSB0d28gbWV0aG9kcyB3aWxsIHJlYXBwZWFyIGJhc2Vk IG9uCj4gYSBzZWN1cmUgYm9vdCBmbGFnIG9mIHNvbWUgc29ydC4KCkkgd2FzIGJsaW5kIHRoZXJl IGZvciBhIG1vbWVudC4gIFllcyB0aGlzIGlzIGFsbCBhYm91dCB0aGUgaW1hIHhhdHRycwphbGxv d2luZyBhIGZpbGUgdG8gYmUgbG9hZGVkLgoKRXJpYwoKCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCmtleGVjIG1haWxpbmcgbGlzdAprZXhlY0BsaXN0cy5p bmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8v a2V4ZWMK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out03.mta.xmission.com ([166.70.13.233]:53265 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751075AbeECPvr (ORCPT ); Thu, 3 May 2018 11:51:47 -0400 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> <87h8nqglpx.fsf@xmission.com> <1525275904.5669.308.camel@linux.vnet.ibm.com> Date: Thu, 03 May 2018 10:51:38 -0500 In-Reply-To: <1525275904.5669.308.camel@linux.vnet.ibm.com> (Mimi Zohar's message of "Wed, 02 May 2018 11:45:04 -0400") Message-ID: <87h8nospo5.fsf@xmission.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Subject: Re: [PATCH 2/3] kexec: call LSM hook for kexec_load syscall Sender: linux-integrity-owner@vger.kernel.org List-ID: Mimi Zohar writes: > On Wed, 2018-05-02 at 09:45 -0500, Eric W. Biederman wrote: >> 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? > > The kexec_file_load() calls kernel_read_file_from_fd(), which in turn > calls security_kernel_read_file(). So kexec_file_load and kexec_load > syscall would be using the same method for enforcing signature > verification. Having looked at your patches and the kernel a little more I think this should be a separate security hook that does not take a file parameter. Right now every other security module assumes !file is init_module. So I think this change has the potential to confuse other security modules, with the result of unintended policy being applied. So just for good security module hygeine I think this needs a dedicated kexec_load security hook. > This is independent of the architecture specific method for verifying > signatures. The coordination between these two methods was included > in the lockdown patch set, but is being removed, as well the gating of > kexec_load syscall. Instead of being based on the lockdown flag, I > assume the coordination between the two methods will reappear based on > a secure boot flag of some sort. I was blind there for a moment. Yes this is all about the ima xattrs allowing a file to be loaded. Eric From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Date: Thu, 03 May 2018 10:51:38 -0500 Subject: [PATCH 2/3] kexec: call LSM hook for kexec_load syscall In-Reply-To: <1525275904.5669.308.camel@linux.vnet.ibm.com> (Mimi Zohar's message of "Wed, 02 May 2018 11:45:04 -0400") References: <1523572911-16363-1-git-send-email-zohar@linux.vnet.ibm.com> <1523572911-16363-3-git-send-email-zohar@linux.vnet.ibm.com> <87h8nqglpx.fsf@xmission.com> <1525275904.5669.308.camel@linux.vnet.ibm.com> Message-ID: <87h8nospo5.fsf@xmission.com> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org Mimi Zohar writes: > On Wed, 2018-05-02 at 09:45 -0500, Eric W. Biederman wrote: >> 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? > > The kexec_file_load() calls kernel_read_file_from_fd(), which in turn > calls security_kernel_read_file(). ?So kexec_file_load and kexec_load > syscall would be using the same method for enforcing signature > verification. Having looked at your patches and the kernel a little more I think this should be a separate security hook that does not take a file parameter. Right now every other security module assumes !file is init_module. So I think this change has the potential to confuse other security modules, with the result of unintended policy being applied. So just for good security module hygeine I think this needs a dedicated kexec_load security hook. > This is independent of the architecture specific method for verifying > signatures. ?The coordination between these two methods was included > in the lockdown patch set, but is being removed, as well the gating of > kexec_load syscall. ?Instead of being based on the lockdown flag, I > assume the coordination between the two methods will reappear based on > a secure boot flag of some sort. I was blind there for a moment. Yes this is all about the ima xattrs allowing a file to be loaded. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751393AbeECPvu convert rfc822-to-8bit (ORCPT ); Thu, 3 May 2018 11:51:50 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:53265 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751075AbeECPvr (ORCPT ); Thu, 3 May 2018 11:51:47 -0400 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> <87h8nqglpx.fsf@xmission.com> <1525275904.5669.308.camel@linux.vnet.ibm.com> Date: Thu, 03 May 2018 10:51:38 -0500 In-Reply-To: <1525275904.5669.308.camel@linux.vnet.ibm.com> (Mimi Zohar's message of "Wed, 02 May 2018 11:45:04 -0400") Message-ID: <87h8nospo5.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-XM-SPF: eid=1fEGWG-0002zB-FU;;;mid=<87h8nospo5.fsf@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=97.119.174.25;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18slK0lIRJP4iUCxF6d4W1L9p1f/MWd4wU= X-SA-Exim-Connect-IP: 97.119.174.25 X-SA-Exim-Mail-From: ebiederm@xmission.com 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.4995] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa03 1397; Body=1 Fuz1=1 Fuz2=1] * 0.1 XMSolicitRefs_0 Weightloss drug * 1.0 T_XMDrugObfuBody_08 obfuscated drug references * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: XMission; sa03 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;Mimi Zohar X-Spam-Relay-Country: X-Spam-Timing: total 587 ms - load_scoreonly_sql: 0.06 (0.0%), signal_user_changed: 3.1 (0.5%), b_tie_ro: 2.2 (0.4%), parse: 1.27 (0.2%), extract_message_metadata: 6 (1.0%), get_uri_detail_list: 2.8 (0.5%), tests_pri_-1000: 6 (1.1%), tests_pri_-950: 2.3 (0.4%), tests_pri_-900: 1.84 (0.3%), tests_pri_-400: 32 (5.5%), check_bayes: 30 (5.1%), b_tokenize: 11 (1.9%), b_tok_get_all: 7 (1.3%), b_comp_prob: 4.6 (0.8%), b_tok_touch_all: 3.0 (0.5%), b_finish: 0.94 (0.2%), tests_pri_0: 504 (85.9%), check_dkim_signature: 0.96 (0.2%), check_dkim_adsp: 4.8 (0.8%), tests_pri_500: 10 (1.6%), 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 List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Mimi Zohar writes: > On Wed, 2018-05-02 at 09:45 -0500, Eric W. Biederman wrote: >> 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? > > The kexec_file_load() calls kernel_read_file_from_fd(), which in turn > calls security_kernel_read_file().  So kexec_file_load and kexec_load > syscall would be using the same method for enforcing signature > verification. Having looked at your patches and the kernel a little more I think this should be a separate security hook that does not take a file parameter. Right now every other security module assumes !file is init_module. So I think this change has the potential to confuse other security modules, with the result of unintended policy being applied. So just for good security module hygeine I think this needs a dedicated kexec_load security hook. > This is independent of the architecture specific method for verifying > signatures.  The coordination between these two methods was included > in the lockdown patch set, but is being removed, as well the gating of > kexec_load syscall.  Instead of being based on the lockdown flag, I > assume the coordination between the two methods will reappear based on > a secure boot flag of some sort. I was blind there for a moment. Yes this is all about the ima xattrs allowing a file to be loaded. Eric