From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from out02.mta.xmission.com ([166.70.13.232]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1fENGh-0007vf-Ly for kexec@lists.infradead.org; Thu, 03 May 2018 23:04:09 +0000 From: ebiederm@xmission.com (Eric W. Biederman) References: <1523572911-16363-1-git-send-email-zohar@linux.vnet.ibm.com> <87r2mso5up.fsf@xmission.com> <1525383075.3539.67.camel@linux.vnet.ibm.com> <87d0yco1vy.fsf@xmission.com> <1525384675.3539.89.camel@linux.vnet.ibm.com> Date: Thu, 03 May 2018 18:03:47 -0500 In-Reply-To: <1525384675.3539.89.camel@linux.vnet.ibm.com> (Mimi Zohar's message of "Thu, 03 May 2018 17:57:55 -0400") Message-ID: <87fu38jq98.fsf@xmission.com> MIME-Version: 1.0 Subject: Re: [PATCH 0/3] kexec: limit 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: Kees Cook , kernel-hardening@lists.openwall.com, 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+IE9uIFRodSwg MjAxOC0wNS0wMyBhdCAxNjozOCAtMDUwMCwgRXJpYyBXLiBCaWVkZXJtYW4gd3JvdGU6Cj4+IE1p bWkgWm9oYXIgPHpvaGFyQGxpbnV4LnZuZXQuaWJtLmNvbT4gd3JpdGVzOgo+PiAKPj4gPiBbQ2Mn aW5nIEtlZXMgYW5kIGtlcm5lbC1oYXJkZW5pbmddCj4+ID4KPj4gPiBPbiBUaHUsIDIwMTgtMDUt MDMgYXQgMTU6MTMgLTA1MDAsIEVyaWMgVy4gQmllZGVybWFuIHdyb3RlOgo+PiA+PiBNaW1pIFpv aGFyIDx6b2hhckBsaW51eC52bmV0LmlibS5jb20+IHdyaXRlczoKPj4gPj4gCj4+ID4+ID4gSW4g ZW52aXJvbm1lbnRzIHRoYXQgcmVxdWlyZSB0aGUga2V4ZWMga2VybmVsIGltYWdlIHRvIGJlIHNp Z25lZCwgcHJldmVudAo+PiA+PiA+IHVzaW5nIHRoZSBrZXhlY19sb2FkIHN5c2NhbGwuICBJbiBv cmRlciBmb3IgTFNNcyBhbmQgSU1BIHRvIGRpZmZlcmVudGlhdGUKPj4gPj4gPiBiZXR3ZWVuIGtl eGVjX2xvYWQgYW5kIGtleGVjX2ZpbGVfbG9hZCBzeXNjYWxscywgdGhpcyBwYXRjaCBzZXQgYWRk cyBhCj4+ID4+ID4gY2FsbCB0byBzZWN1cml0eV9rZXJuZWxfcmVhZF9maWxlKCkgaW4ga2V4ZWNf bG9hZF9jaGVjaygpLgo+PiA+PiAKPj4gPj4gSGF2aW5nIHRob3VnaHQgYWJvdXQgaXQgc29tZSBt b3JlIHRoaXMganVzdGlmaWNhdGlvbiBmb3IgdGhlc2UgY2hhbmdlcwo+PiA+PiBkb2VzIG5vdCB3 b3JrLiAgVGhlIGZ1bmN0aW9uYWxpdHkgb2Yga2V4ZWNfbG9hZCBpcyBhbHJlYWR5IHJvb3Qtb25s eS4KPj4gPj4gU28gaW4gZW52aXJvbm1lbnRzIHRoYXQgcmVxdWlyZSB0aGUga2VybmVsIGltYWdl IHRvIGJlIHNpZ25lZCBqdXN0IGRvbid0Cj4+ID4+IHVzZSBrZXhlY19sb2FkLiAgUG9zc2libHkg ZXZlbiBjb21waWxlIGtleGVjX2xvYWQgb3V0IHRvIHNhdmUgc3BhY2UKPj4gPj4gYmVjYXVzZSB5 b3Ugd2lsbCBuZXZlciBuZWVkIGl0LiAgWW91IGRvbid0IG5lZWQgYSBuZXcgc2VjdXJpdHkgaG9v ayB0bwo+PiA+PiBkbyBhbnkgb2YgdGhhdC4gIFVzZXJzcGFjZSBpcyBhIHZlcnkgZmluZSBtZWNo YW5pc20gZm9yIGJlaW5nIHRoZQo+PiA+PiBpbnN0cnVtZW50IG9mIHBvbGljeS4KPj4gPgo+PiA+ IFRydWUsIGZvciB0aG9zZSBidWlsZGluZyB0aGVpciBvd24ga2VybmVsLCB0aGV5IGNhbiBkaXNh YmxlIHRoZSBvbGQKPj4gPiBzeXNjYWxscy4gwqBUaGUgY29uY2VybiBpcyBub3QgZm9yIHRob3Nl IGJ1aWxkaW5nIHRoZWlyIG93biBrZXJuZWxzLAo+PiA+IGJ1dCBmb3IgdGhvc2UgdXNpbmcgc3Rv Y2sga2VybmVscy4gwqAKPj4gPgo+PiA+IEJ5IGFkZGluZyBhbiBMU00gaG9vayBoZXJlIGluIHRo ZSBrZXhlY19sb2FkIHN5c2NhbGwsIGFzIG9wcG9zZWQgdG8gYW4KPj4gPiBJTUEgc3BlY2lmaWMg aG9vaywgb3RoZXIgTFNNcyBjYW4gcGlnZ3kgYmFjayBvbiB0b3Agb2YgaXQuIMKgQ3VycmVudGx5 LAo+PiA+IGJvdGggbG9hZF9waW4gYW5kIFNFTGludXggYXJlIGdhdGluZyB0aGUga2VybmVsIG1v ZHVsZSBzeXNjYWxscyBiYXNlZAo+PiA+IG9uIHNlY3VyaXR5X2tlcm5lbF9yZWFkX2ZpbGUuCj4+ ID4KPj4gPiBJZiB0aGVyZSB3YXMgYSBzaW1pbGFyIG9wdGlvbiBmb3IgdGhlIGtlcm5lbCBpbWFn ZSwgSSdtIHByZXR0eSBzdXJlCj4+ID4gb3RoZXIgTFNNcyB3b3VsZCB1c2UgaXQuCj4+ID4KPj4g PiBGcm9tIGFuIElNQSBwZXJzcGVjdGl2ZSwgdGhlcmUgbmVlZHMgdG8gYmUgc29tZSBtZXRob2Qg Zm9yIG9ubHkKPj4gPiBhbGxvd2luZyBzaWduZWQgY29kZSB0byBiZSBsb2FkZWQsIGV4ZWN1dGVk LCBldGMuIC0ga2VybmVsIG1vZHVsZXMsCj4+ID4ga2VybmVsIGltYWdlL2luaXRyYW1mcywgZmly bXdhcmUsIHBvbGljaWVzLgo+PiAKPj4gV2hhdCBpcyB0aGUgSU1BIHBlcnNwZWN0aXZlLiAgV2h5 IGNhbid0IElNQSB0cnVzdCBhcHByb3ByaWF0ZWx5Cj4+IGF1dGhvcml6ZWQgdXNlcnNwYWNlPwo+ Cj4gU3VwcG9zZSBhIHN5c3RlbSBvd25lciB3YW50cyB0byBkZWZpbmUgYSBzeXN0ZW0gd2lkZSBw b2xpY3kgdGhhdAo+IHJlcXVpcmVzIGFsbCBjb2RlIGJlIHNpZ25lZCAtIGtlcm5lbCBtb2R1bGVz LCBmaXJtd2FyZSwga2V4ZWMgaW1hZ2UgJgo+IGluaXRyYW1mcywgZXhlY3V0YWJsZXMsIG1tYXBw ZWQgZmlsZXMsIGV0YyAtIHdpdGhvdXQgaGF2aW5nIHRvIHJlYnVpbGQKPiB0aGUga2VybmVsLiDC oFdpdGhvdXQgYSBjYWxsIGluIGtleGVjX2xvYWQgdGhhdCBpc24ndCBwb3NzaWJsZS4KCk9mIGNv dXJzZSBpdCBpcy4gIFlvdSBqdXN0IG1ha2UgaXQgYSByZXF1aXJlbWVudCB0aGF0IGJlZm9yZSBh bgpleGVjdXRhYmxlIHdpbGwgYmUgc2lnbmVkIGl0IHdpbGwgYmUgYXVkaXRlZCB0byBzZWUgdGhh dCBpdCBkb2Vzbid0CmNhbGwgc3lzX2tleGVjX2xvYWQuICBTaWduaW5nIHByZXN1bWFibHkgbWVh bnMgc29tZXRoaW5nLiAgU28gaXQgc2hvdWxkCm5vdCBiZSBoYXJkIHRvIGVuZm9yY2UgYSBwb2xp Y3kgbGlrZSB0aGF0IG9uIGEgc3BlY2lhbHR5IHN5c3RlbSBjYWxsCnRoYXQgbW9zdCBhcHBsaWNh dGlvbnMgd2lsbCBuZXZlciBjYWxsLgoKPj4gPj4gSWYgeW91IGRvbid0IHRydXN0IHVzZXJzcGFj ZSB0aGF0IG5lZWRzIHRvIGJlIHNwZWxsZWQgb3V0IHZlcnkgY2xlYXJseS4KPj4gPj4gWW91IG5l ZWQgdG8gdGFsayBhYm91dCB3aGF0IHlvdXIgdGhyZWF0IG1vZGVscyBhcmUuCj4+ID4+IAo+PiA+ PiBJZiB0aGUgb25seSBqdXN0aWZpY2F0aW9uIGlzIHNvIHRoYXQgdGhhdCB3ZSBjYW4ndCBib290 IHdpbmRvd3MgaWYKPj4gPj4gc29tZW9uZSBoYWNrcyBpbnRvIHVzZXJzcGFjZSBpdCBoYXMgbXkg bmFjayBiZWNhdXNlIHRoYXQgaXMgYW5vdGhlciBraW5kCj4+ID4+IG9mIGNvbXBsZXRlIG5vbi1z ZW5zZS4KPj4gPgo+PiA+IFRoZSB1c2VjYXNlIGlzIHRoZSBhYmlsaXR5IHRvIGdhdGUgdGhlIGtl eGVjX2xvYWQgdXNhZ2UgaW4gc3RvY2sKPj4gPiBrZXJuZWxzLgo+PiAKPj4gQnV0IGtleGVjX2xv YWQgaXMgYWxyZWFkeSBnYXRlZC4gIEl0IHJlcXVpcmVzIENBUF9TWVNfQk9PVC4KPgo+IEl0IGlz bid0IGEgbWF0dGVyIG9mIGtleGVjX2xvYWQgYWxyZWFkeSBiZWluZyBnYXRlZCwgYnV0IG9mIHdh bnRpbmcgYQo+IHNpbmdsZSBwbGFjZSBmb3IgZGVmaW5pbmcgYSBzeXN0ZW0gd2lkZSBwb2xpY3ks IGFzIGRlc2NyaWJlZCBhYm92ZS4KClNpZ25pbmcgaXMgb25seSBhIHRvb2wgdG8gZW5mb3JjZSBh IHBvbGljeS4gIFNpZ25pbmcgYnkgaXRzZWxmIGlzIG5vdCBhCnBvbGljeS4gIEVuZm9yY2luZyBh bnkgcXVhbGl0eSBjb250cm9scyBpbiB0aGUgc2lnbmVkIGV4ZWN1dGFibGVzIHNob3VsZAp0cml2 aWFsbHkgcHJldmVudCBrZXhlY19sb2FkIGZyb20gYmVpbmcgdXNlZC4KCkVyaWMKCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmtleGVjIG1haWxpbmcgbGlz dAprZXhlY0BsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21h aWxtYW4vbGlzdGluZm8va2V4ZWMK From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) References: <1523572911-16363-1-git-send-email-zohar@linux.vnet.ibm.com> <87r2mso5up.fsf@xmission.com> <1525383075.3539.67.camel@linux.vnet.ibm.com> <87d0yco1vy.fsf@xmission.com> <1525384675.3539.89.camel@linux.vnet.ibm.com> Date: Thu, 03 May 2018 18:03:47 -0500 In-Reply-To: <1525384675.3539.89.camel@linux.vnet.ibm.com> (Mimi Zohar's message of "Thu, 03 May 2018 17:57:55 -0400") Message-ID: <87fu38jq98.fsf@xmission.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH 0/3] kexec: limit kexec_load syscall To: Mimi Zohar Cc: Kees Cook , David Howells , Matthew Garrett , linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com List-ID: Mimi Zohar writes: > On Thu, 2018-05-03 at 16:38 -0500, Eric W. Biederman wrote: >> Mimi Zohar writes: >>=20 >> > [Cc'ing Kees and kernel-hardening] >> > >> > On Thu, 2018-05-03 at 15:13 -0500, Eric W. Biederman wrote: >> >> Mimi Zohar writes: >> >>=20 >> >> > In environments that require the kexec kernel image to be signed, p= revent >> >> > using the kexec_load syscall. In order for LSMs and IMA to differe= ntiate >> >> > between kexec_load and kexec_file_load syscalls, this patch set add= s a >> >> > call to security_kernel_read_file() in kexec_load_check(). >> >>=20 >> >> Having thought about it some more this justification for these changes >> >> does not work. The functionality of kexec_load is already root-only. >> >> So in environments that require the kernel image to be signed just do= n't >> >> use kexec_load. Possibly even compile kexec_load out to save space >> >> because you will never need it. You don't need a new security hook to >> >> do any of that. Userspace is a very fine mechanism for being the >> >> instrument of policy. >> > >> > True, for those building their own kernel, they can disable the old >> > syscalls. =C2=A0The concern is not for those building their own kernel= s, >> > but for those using stock kernels. =C2=A0 >> > >> > By adding an LSM hook here in the kexec_load syscall, as opposed to an >> > IMA specific hook, other LSMs can piggy back on top of it. =C2=A0Curre= ntly, >> > both load_pin and SELinux are gating the kernel module syscalls based >> > on security_kernel_read_file. >> > >> > If there was a similar option for the kernel image, I'm pretty sure >> > other LSMs would use it. >> > >> > From an IMA perspective, there needs to be some method for only >> > allowing signed code to be loaded, executed, etc. - kernel modules, >> > kernel image/initramfs, firmware, policies. >>=20 >> What is the IMA perspective. Why can't IMA trust appropriately >> authorized userspace? > > Suppose a system owner wants to define a system wide policy that > requires all code be signed - kernel modules, firmware, kexec image & > initramfs, executables, mmapped files, etc - without having to rebuild > the kernel. =C2=A0Without a call in kexec_load that isn't possible. Of course it is. You just make it a requirement that before an executable will be signed it will be audited to see that it doesn't call sys_kexec_load. Signing presumably means something. So it should not be hard to enforce a policy like that on a specialty system call that most applications will never call. >> >> If you don't trust userspace that needs to be spelled out very clearl= y. >> >> You need to talk about what your threat models are. >> >>=20 >> >> If the only justification is so that that we can't boot windows if >> >> someone hacks into userspace it has my nack because that is another k= ind >> >> of complete non-sense. >> > >> > The usecase is the ability to gate the kexec_load usage in stock >> > kernels. >>=20 >> But kexec_load is already gated. It requires CAP_SYS_BOOT. > > It isn't a matter of kexec_load already being gated, but of wanting a > single place for defining a system wide policy, as described above. Signing is only a tool to enforce a policy. Signing by itself is not a policy. Enforcing any quality controls in the signed executables should trivially prevent kexec_load from being used. Eric From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out02.mta.xmission.com ([166.70.13.232]:59403 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751111AbeECXD4 (ORCPT ); Thu, 3 May 2018 19:03:56 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Mimi Zohar Cc: Kees Cook , David Howells , Matthew Garrett , linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com References: <1523572911-16363-1-git-send-email-zohar@linux.vnet.ibm.com> <87r2mso5up.fsf@xmission.com> <1525383075.3539.67.camel@linux.vnet.ibm.com> <87d0yco1vy.fsf@xmission.com> <1525384675.3539.89.camel@linux.vnet.ibm.com> Date: Thu, 03 May 2018 18:03:47 -0500 In-Reply-To: <1525384675.3539.89.camel@linux.vnet.ibm.com> (Mimi Zohar's message of "Thu, 03 May 2018 17:57:55 -0400") Message-ID: <87fu38jq98.fsf@xmission.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Subject: Re: [PATCH 0/3] kexec: limit kexec_load syscall Sender: linux-integrity-owner@vger.kernel.org List-ID: Mimi Zohar writes: > On Thu, 2018-05-03 at 16:38 -0500, Eric W. Biederman wrote: >> Mimi Zohar writes: >> >> > [Cc'ing Kees and kernel-hardening] >> > >> > On Thu, 2018-05-03 at 15:13 -0500, Eric W. Biederman wrote: >> >> Mimi Zohar writes: >> >> >> >> > In environments that require the kexec kernel image to be signed, prevent >> >> > using the kexec_load syscall. In order for LSMs and IMA to differentiate >> >> > between kexec_load and kexec_file_load syscalls, this patch set adds a >> >> > call to security_kernel_read_file() in kexec_load_check(). >> >> >> >> Having thought about it some more this justification for these changes >> >> does not work. The functionality of kexec_load is already root-only. >> >> So in environments that require the kernel image to be signed just don't >> >> use kexec_load. Possibly even compile kexec_load out to save space >> >> because you will never need it. You don't need a new security hook to >> >> do any of that. Userspace is a very fine mechanism for being the >> >> instrument of policy. >> > >> > True, for those building their own kernel, they can disable the old >> > syscalls. The concern is not for those building their own kernels, >> > but for those using stock kernels. >> > >> > By adding an LSM hook here in the kexec_load syscall, as opposed to an >> > IMA specific hook, other LSMs can piggy back on top of it. Currently, >> > both load_pin and SELinux are gating the kernel module syscalls based >> > on security_kernel_read_file. >> > >> > If there was a similar option for the kernel image, I'm pretty sure >> > other LSMs would use it. >> > >> > From an IMA perspective, there needs to be some method for only >> > allowing signed code to be loaded, executed, etc. - kernel modules, >> > kernel image/initramfs, firmware, policies. >> >> What is the IMA perspective. Why can't IMA trust appropriately >> authorized userspace? > > Suppose a system owner wants to define a system wide policy that > requires all code be signed - kernel modules, firmware, kexec image & > initramfs, executables, mmapped files, etc - without having to rebuild > the kernel. Without a call in kexec_load that isn't possible. Of course it is. You just make it a requirement that before an executable will be signed it will be audited to see that it doesn't call sys_kexec_load. Signing presumably means something. So it should not be hard to enforce a policy like that on a specialty system call that most applications will never call. >> >> If you don't trust userspace that needs to be spelled out very clearly. >> >> You need to talk about what your threat models are. >> >> >> >> If the only justification is so that that we can't boot windows if >> >> someone hacks into userspace it has my nack because that is another kind >> >> of complete non-sense. >> > >> > The usecase is the ability to gate the kexec_load usage in stock >> > kernels. >> >> But kexec_load is already gated. It requires CAP_SYS_BOOT. > > It isn't a matter of kexec_load already being gated, but of wanting a > single place for defining a system wide policy, as described above. Signing is only a tool to enforce a policy. Signing by itself is not a policy. Enforcing any quality controls in the signed executables should trivially prevent kexec_load from being used. Eric From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Date: Thu, 03 May 2018 18:03:47 -0500 Subject: [PATCH 0/3] kexec: limit kexec_load syscall In-Reply-To: <1525384675.3539.89.camel@linux.vnet.ibm.com> (Mimi Zohar's message of "Thu, 03 May 2018 17:57:55 -0400") References: <1523572911-16363-1-git-send-email-zohar@linux.vnet.ibm.com> <87r2mso5up.fsf@xmission.com> <1525383075.3539.67.camel@linux.vnet.ibm.com> <87d0yco1vy.fsf@xmission.com> <1525384675.3539.89.camel@linux.vnet.ibm.com> Message-ID: <87fu38jq98.fsf@xmission.com> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org Mimi Zohar writes: > On Thu, 2018-05-03 at 16:38 -0500, Eric W. Biederman wrote: >> Mimi Zohar writes: >> >> > [Cc'ing Kees and kernel-hardening] >> > >> > On Thu, 2018-05-03 at 15:13 -0500, Eric W. Biederman wrote: >> >> Mimi Zohar writes: >> >> >> >> > In environments that require the kexec kernel image to be signed, prevent >> >> > using the kexec_load syscall. In order for LSMs and IMA to differentiate >> >> > between kexec_load and kexec_file_load syscalls, this patch set adds a >> >> > call to security_kernel_read_file() in kexec_load_check(). >> >> >> >> Having thought about it some more this justification for these changes >> >> does not work. The functionality of kexec_load is already root-only. >> >> So in environments that require the kernel image to be signed just don't >> >> use kexec_load. Possibly even compile kexec_load out to save space >> >> because you will never need it. You don't need a new security hook to >> >> do any of that. Userspace is a very fine mechanism for being the >> >> instrument of policy. >> > >> > True, for those building their own kernel, they can disable the old >> > syscalls. ?The concern is not for those building their own kernels, >> > but for those using stock kernels. ? >> > >> > By adding an LSM hook here in the kexec_load syscall, as opposed to an >> > IMA specific hook, other LSMs can piggy back on top of it. ?Currently, >> > both load_pin and SELinux are gating the kernel module syscalls based >> > on security_kernel_read_file. >> > >> > If there was a similar option for the kernel image, I'm pretty sure >> > other LSMs would use it. >> > >> > From an IMA perspective, there needs to be some method for only >> > allowing signed code to be loaded, executed, etc. - kernel modules, >> > kernel image/initramfs, firmware, policies. >> >> What is the IMA perspective. Why can't IMA trust appropriately >> authorized userspace? > > Suppose a system owner wants to define a system wide policy that > requires all code be signed - kernel modules, firmware, kexec image & > initramfs, executables, mmapped files, etc - without having to rebuild > the kernel. ?Without a call in kexec_load that isn't possible. Of course it is. You just make it a requirement that before an executable will be signed it will be audited to see that it doesn't call sys_kexec_load. Signing presumably means something. So it should not be hard to enforce a policy like that on a specialty system call that most applications will never call. >> >> If you don't trust userspace that needs to be spelled out very clearly. >> >> You need to talk about what your threat models are. >> >> >> >> If the only justification is so that that we can't boot windows if >> >> someone hacks into userspace it has my nack because that is another kind >> >> of complete non-sense. >> > >> > The usecase is the ability to gate the kexec_load usage in stock >> > kernels. >> >> But kexec_load is already gated. It requires CAP_SYS_BOOT. > > It isn't a matter of kexec_load already being gated, but of wanting a > single place for defining a system wide policy, as described above. Signing is only a tool to enforce a policy. Signing by itself is not a policy. Enforcing any quality controls in the signed executables should trivially prevent kexec_load from being used. 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