Re: [RFC] Kdump with signed images
On Wed, Oct 24, 2012 at 10:43 PM, Mimi Zohar zo...@linux.vnet.ibm.com wrote: On Wed, 2012-10-24 at 13:19 -0400, Vivek Goyal wrote: On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote: Matthew Garrett m...@redhat.com writes: On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote: But what about creation of a new program which can call kexec_load() and execute an unsigned kernel. Doesn't look like that will be prevented using IMA. Like the existing kernel modules, kexec_load() is not file descriptor based. There isn't an LSM or IMA-appraisal hook here. Right. Trusting userspace would require a new system call that passes in a signature of the userspace binary, and the kernel would then have to verify the ELF object in memory in order to ensure that it matches the signature. Verifying that the copy on the filesystem is unmodified isn't adequate - an attacker could simply have paused the process and injected code. I haven't looked at kexec_load() in detail, but like kernel modules, I think the better solution would be to pass a file descriptor, especially if you're discussing a new system call. (cc'ing Kees.) Yeah, it looks like kexec_load could use a nearly identical new syscall that uses an fd, just like init_module is getting. Another area, kind of related, is firmware loading. The interface for that is a bit weird, if the documentation is up to date: echo 1 /sys/$DEVPATH/loading cat $HOTPLUG_FW_DIR/$FIRMWARE /sysfs/$DEVPATH/data echo 0 /sys/$DEVPATH/loading It looks like there's a filp on the reader: static ssize_t firmware_data_read(struct file *filp, struct kobject *kobj, struct bin_attribute *bin_attr, char *buffer, loff_t offset, size_t count) But it's not clear to me yet if we'll actually get the firmware file, or if we'll get a random pipe we can't evaluate. Has anyone looked at handling signed firmware loading yet? -Kees -- Kees Cook Chrome OS Security ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [RFC] Kdump with signed images
On Thu, Oct 25, 2012 at 01:43:59AM -0400, Mimi Zohar wrote: On Wed, 2012-10-24 at 13:19 -0400, Vivek Goyal wrote: On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote: Matthew Garrett m...@redhat.com writes: On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote: But what about creation of a new program which can call kexec_load() and execute an unsigned kernel. Doesn't look like that will be prevented using IMA. Like the existing kernel modules, kexec_load() is not file descriptor based. There isn't an LSM or IMA-appraisal hook here. Right. Trusting userspace would require a new system call that passes in a signature of the userspace binary, and the kernel would then have to verify the ELF object in memory in order to ensure that it matches the signature. Verifying that the copy on the filesystem is unmodified isn't adequate - an attacker could simply have paused the process and injected code. I haven't looked at kexec_load() in detail, but like kernel modules, I think the better solution would be to pass a file descriptor, especially if you're discussing a new system call. (cc'ing Kees.) If we decide to go for a new system call, then yes it looks like passing fd will make sense. Verifying the copy on the filesystem at exec time is perfectly adequate for gating extra permissions. Certainly that is the model everywhere else in the signed key chain. Where IMA falls short is there is no offline signing capability in IMA itself. I think EVM may fix that. I'm not sure what you mean by offline signing capability. IMA-appraisal verifies a file's 'security.ima' xattr, which may contain a hash or a digital signature. EVM protects a file's metadata, including 'security.ima'. 'security.evm' can be either an hmac or a digital signature. By offline we mean that signature generation/signing does not happen on system in question. It happens say on build time. IIUC, in case of IMA, security.ima is generated and signed on the system and that means private key needs to be present on the system? We wanted something like module signing where modules are signed at build time and verification happens at load time but no private key needs to be present on the system. [ CCing lkml. I think it is a good idea to open discussion to wider audience. Also CCing IMA/EVM folks ] thanks! Based on reading following wiki page, looks like EVM also does not allow offline signing capability. And EVM is protecting IMA data to protect against offline attack. If we can assume that unisgned kernels can't be booted on the platform, then EVM might not be a strict requirement in this case. So as you said, one of the main problem with IMA use to verify /sbin/kexec is that IMA does not provide offline signing capability. ? See above. Realistically, the only solution here is for the kernel to verify that the kernel it's about to boot is signed and for it not to take any untrusted executable code from userspace. From an IMA, as opposed to an IMA-appraisal, perspective, kexec is problematic. IMA maintains a measurement list and extends a PCR with the file hash. The measurement list and PCR value are used to attest to the integrity of the running system. As the original measurement list is lost after kexec, but the PCR value hasn't been reset, the measuremnet list and PCR value won't agree. Hogwash. The kernel verifing a signature of /sbin/kexec at exec time is perfectly reasonable, and realistic. In fact finding a way to trust small bits of userspace even if root is compromised seems a far superior model to simply solving the signing problem for /sbin/kexec. Huh? I don't understand what you're suggesting. Once root has been compromised, that's it. Although I do admit some part of the kexec process will need to verify keys on the images we decide to boot. Which keys? Isn't the kernel module key builtin to the kernel and included in the kernel image signature? I think Eric is referring to verifying bzImage signature. One can sign PE/COFF bzImage so IIUC, Eric seems to be suggesting that let /sbin/kexec verify the integrity/authenticity of bzImage and figure a way out to verify integrity/authenticity of /sbin/kexec. That way one does not have to change current logic and most of the logic of kexec/kdump can still be in user space. Otherwise we shall probably have to implement a new system call which takes kernel and initrd as input parameters and kernel does signature verification and prepares bzImage for loading. This is like re-writing kexec/kdump again with restricted functionality. Thanks Vivek ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [RFC] Kdump with signed images
On Thu, 2012-10-25 at 09:54 -0400, Vivek Goyal wrote: On Thu, Oct 25, 2012 at 01:43:59AM -0400, Mimi Zohar wrote: On Wed, 2012-10-24 at 13:19 -0400, Vivek Goyal wrote: On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote: Matthew Garrett m...@redhat.com writes: On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote: But what about creation of a new program which can call kexec_load() and execute an unsigned kernel. Doesn't look like that will be prevented using IMA. Like the existing kernel modules, kexec_load() is not file descriptor based. There isn't an LSM or IMA-appraisal hook here. Right. Trusting userspace would require a new system call that passes in a signature of the userspace binary, and the kernel would then have to verify the ELF object in memory in order to ensure that it matches the signature. Verifying that the copy on the filesystem is unmodified isn't adequate - an attacker could simply have paused the process and injected code. I haven't looked at kexec_load() in detail, but like kernel modules, I think the better solution would be to pass a file descriptor, especially if you're discussing a new system call. (cc'ing Kees.) If we decide to go for a new system call, then yes it looks like passing fd will make sense. Verifying the copy on the filesystem at exec time is perfectly adequate for gating extra permissions. Certainly that is the model everywhere else in the signed key chain. Where IMA falls short is there is no offline signing capability in IMA itself. I think EVM may fix that. I'm not sure what you mean by offline signing capability. IMA-appraisal verifies a file's 'security.ima' xattr, which may contain a hash or a digital signature. EVM protects a file's metadata, including 'security.ima'. 'security.evm' can be either an hmac or a digital signature. By offline we mean that signature generation/signing does not happen on system in question. It happens say on build time. IIUC, in case of IMA, security.ima is generated and signed on the system and that means private key needs to be present on the system? The signature for 'security.ima' can definitely be created offline. 'security.evm' can also be created offline, as long as the target's inode and other metadata doesn't change. We wanted something like module signing where modules are signed at build time and verification happens at load time but no private key needs to be present on the system. Modules are identifiable. As long as you have some mechanism to identify mutable vs immutable files during build, there shouldn't be a problem. I'd use the same private key for signing modules and all others. [ CCing lkml. I think it is a good idea to open discussion to wider audience. Also CCing IMA/EVM folks ] thanks! Based on reading following wiki page, looks like EVM also does not allow offline signing capability. And EVM is protecting IMA data to protect against offline attack. If we can assume that unisgned kernels can't be booted on the platform, then EVM might not be a strict requirement in this case. So as you said, one of the main problem with IMA use to verify /sbin/kexec is that IMA does not provide offline signing capability. ? See above. Realistically, the only solution here is for the kernel to verify that the kernel it's about to boot is signed and for it not to take any untrusted executable code from userspace. From an IMA, as opposed to an IMA-appraisal, perspective, kexec is problematic. IMA maintains a measurement list and extends a PCR with the file hash. The measurement list and PCR value are used to attest to the integrity of the running system. As the original measurement list is lost after kexec, but the PCR value hasn't been reset, the measuremnet list and PCR value won't agree. Hogwash. The kernel verifing a signature of /sbin/kexec at exec time is perfectly reasonable, and realistic. In fact finding a way to trust small bits of userspace even if root is compromised seems a far superior model to simply solving the signing problem for /sbin/kexec. Huh? I don't understand what you're suggesting. Once root has been compromised, that's it. Although I do admit some part of the kexec process will need to verify keys on the images we decide to boot. Which keys? Isn't the kernel module key builtin to the kernel and included in the kernel image signature? I think Eric is referring to verifying bzImage signature. One can sign PE/COFF bzImage so IIUC, Eric seems to be suggesting that let /sbin/kexec verify the integrity/authenticity of bzImage and figure a way out to verify integrity/authenticity of /sbin/kexec. Yes that would work. IMA-appraisal/EVM would verify and enforce the
Re: [RFC] Kdump with signed images
On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote: Matthew Garrett m...@redhat.com writes: On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote: But what about creation of a new program which can call kexec_load() and execute an unsigned kernel. Doesn't look like that will be prevented using IMA. Right. Trusting userspace would require a new system call that passes in a signature of the userspace binary, and the kernel would then have to verify the ELF object in memory in order to ensure that it matches the signature. Verifying that the copy on the filesystem is unmodified isn't adequate - an attacker could simply have paused the process and injected code. Verifying the copy on the filesystem at exec time is perfectly adequate for gating extra permissions. Certainly that is the model everywhere else in the signed key chain. Where IMA falls short is there is no offline signing capability in IMA itself. I think EVM may fix that. [ CCing lkml. I think it is a good idea to open discussion to wider audience. Also CCing IMA/EVM folks ] Based on reading following wiki page, looks like EVM also does not allow offline signing capability. And EVM is protecting IMA data to protect against offline attack. If we can assume that unisgned kernels can't be booted on the platform, then EVM might not be a strict requirement in this case. So as you said, one of the main problem with IMA use to verify /sbin/kexec is that IMA does not provide offline signing capability. Realistically, the only solution here is for the kernel to verify that the kernel it's about to boot is signed and for it not to take any untrusted executable code from userspace. Hogwash. The kernel verifing a signature of /sbin/kexec at exec time is perfectly reasonable, and realistic. In fact finding a way to trust small bits of userspace even if root is compromised seems a far superior model to simply solving the signing problem for /sbin/kexec. Although I do admit some part of the kexec process will need to verify keys on the images we decide to boot. It should be an option, isn't it? Either /sbin/kexec can try to verify the integrity of kernel or we extend try to extend kexec() system call to also pass the signature of kernel and let kernel verify it (as you mentioned previously). Thanks Vivek ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [RFC] Kdump with signed images
On Wed, 2012-10-24 at 13:19 -0400, Vivek Goyal wrote: On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote: Matthew Garrett m...@redhat.com writes: On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote: But what about creation of a new program which can call kexec_load() and execute an unsigned kernel. Doesn't look like that will be prevented using IMA. Like the existing kernel modules, kexec_load() is not file descriptor based. There isn't an LSM or IMA-appraisal hook here. Right. Trusting userspace would require a new system call that passes in a signature of the userspace binary, and the kernel would then have to verify the ELF object in memory in order to ensure that it matches the signature. Verifying that the copy on the filesystem is unmodified isn't adequate - an attacker could simply have paused the process and injected code. I haven't looked at kexec_load() in detail, but like kernel modules, I think the better solution would be to pass a file descriptor, especially if you're discussing a new system call. (cc'ing Kees.) Verifying the copy on the filesystem at exec time is perfectly adequate for gating extra permissions. Certainly that is the model everywhere else in the signed key chain. Where IMA falls short is there is no offline signing capability in IMA itself. I think EVM may fix that. I'm not sure what you mean by offline signing capability. IMA-appraisal verifies a file's 'security.ima' xattr, which may contain a hash or a digital signature. EVM protects a file's metadata, including 'security.ima'. 'security.evm' can be either an hmac or a digital signature. [ CCing lkml. I think it is a good idea to open discussion to wider audience. Also CCing IMA/EVM folks ] thanks! Based on reading following wiki page, looks like EVM also does not allow offline signing capability. And EVM is protecting IMA data to protect against offline attack. If we can assume that unisgned kernels can't be booted on the platform, then EVM might not be a strict requirement in this case. So as you said, one of the main problem with IMA use to verify /sbin/kexec is that IMA does not provide offline signing capability. ? Realistically, the only solution here is for the kernel to verify that the kernel it's about to boot is signed and for it not to take any untrusted executable code from userspace. From an IMA, as opposed to an IMA-appraisal, perspective, kexec is problematic. IMA maintains a measurement list and extends a PCR with the file hash. The measurement list and PCR value are used to attest to the integrity of the running system. As the original measurement list is lost after kexec, but the PCR value hasn't been reset, the measuremnet list and PCR value won't agree. Hogwash. The kernel verifing a signature of /sbin/kexec at exec time is perfectly reasonable, and realistic. In fact finding a way to trust small bits of userspace even if root is compromised seems a far superior model to simply solving the signing problem for /sbin/kexec. Huh? I don't understand what you're suggesting. Once root has been compromised, that's it. Although I do admit some part of the kexec process will need to verify keys on the images we decide to boot. Which keys? Isn't the kernel module key builtin to the kernel and included in the kernel image signature? It should be an option, isn't it? Either /sbin/kexec can try to verify the integrity of kernel or we extend try to extend kexec() system call to also pass the signature of kernel and let kernel verify it (as you mentioned previously). Thanks Vivek As suggested above, please consider passing a file descriptor, at least in addition, if not in lieu of a signature. thanks, Mimi ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [RFC] Kdump with signed images.
Vivek Goyal vgo...@redhat.com writes: On Tue, Oct 23, 2012 at 11:04:29AM +0900, Simon Horman wrote: On Mon, Oct 22, 2012 at 04:43:39PM -0400, Vivek Goyal wrote: On Fri, Oct 19, 2012 at 10:31:12AM -0400, Vivek Goyal wrote: [..] - What happens to purgatory code. It is unsigned piece of code which runs in kernel? Thinking more about it, another not so clean proposal. I have always assumed that purgatory can't be removed as doing so would break backwards compatibility. Hi Simon, I think this will be a new parallel path and this new path should be taken only on kernel booted with secure boot enabled. (Either automatically or by using some kexec command line option). So nothing should be broken because we never supported anything on secure boot enabled system. Rubbish. Kexec works just fine today on a secure boot enabled system. Ignoring the nonsense that there is no such thing as a secure boot enabled linux system. Whatever we implement must work on all linux systems. If we implement an extension we also must write the code in /sbin/kexec so that it works on older systems that do not implement that extension. Eric ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [RFC] Kdump with signed images
Matthew Garrett m...@redhat.com writes: On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote: But what about creation of a new program which can call kexec_load() and execute an unsigned kernel. Doesn't look like that will be prevented using IMA. Right. Trusting userspace would require a new system call that passes in a signature of the userspace binary, and the kernel would then have to verify the ELF object in memory in order to ensure that it matches the signature. Verifying that the copy on the filesystem is unmodified isn't adequate - an attacker could simply have paused the process and injected code. Verifying the copy on the filesystem at exec time is perfectly adequate for gating extra permissions. Certainly that is the model everywhere else in the signed key chain. Where IMA falls short is there is no offline signing capability in IMA itself. I think EVM may fix that. Realistically, the only solution here is for the kernel to verify that the kernel it's about to boot is signed and for it not to take any untrusted executable code from userspace. Hogwash. The kernel verifing a signature of /sbin/kexec at exec time is perfectly reasonable, and realistic. In fact finding a way to trust small bits of userspace even if root is compromised seems a far superior model to simply solving the signing problem for /sbin/kexec. Although I do admit some part of the kexec process will need to verify keys on the images we decide to boot. Eric ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [RFC] Kdump with signed images
On Tue, Oct 23, 2012 at 09:44:59AM -0700, Eric W. Biederman wrote: Hogwash. The kernel verifing a signature of /sbin/kexec at exec time is perfectly reasonable, and realistic. In fact finding a way to trust small bits of userspace even if root is compromised seems a far superior model to simply solving the signing problem for /sbin/kexec. The kernel verifying the signature of /sbin/kexec and then knowing that it should only grant permission to make this syscall to /sbin/kexec, without that policy being provided by userspace. -- Matthew Garrett | mj...@srcf.ucam.org ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [RFC] Kdump with signed images.
On Tue, Oct 23, 2012 at 09:26:32AM -0700, Eric W. Biederman wrote: [..] I think this will be a new parallel path and this new path should be taken only on kernel booted with secure boot enabled. (Either automatically or by using some kexec command line option). So nothing should be broken because we never supported anything on secure boot enabled system. Rubbish. Kexec works just fine today on a secure boot enabled system. Ignoring the nonsense that there is no such thing as a secure boot enabled linux system. I think it is a security hole for the systems where we don't want to run unsigned priviliged code. So yes, it works as of today, but at some point of time we shall have to close this hole. Thanks Vivek ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [RFC] Kdump with signed images.
On Tue, Oct 23, 2012 at 11:11:05PM +0400, Maxim Uvarov wrote: 2012/10/23 Vivek Goyal vgo...@redhat.com: On Tue, Oct 23, 2012 at 09:26:32AM -0700, Eric W. Biederman wrote: [..] I think this will be a new parallel path and this new path should be taken only on kernel booted with secure boot enabled. (Either automatically or by using some kexec command line option). So nothing should be broken because we never supported anything on secure boot enabled system. Rubbish. Kexec works just fine today on a secure boot enabled system. Ignoring the nonsense that there is no such thing as a secure boot enabled linux system. I think it is a security hole for the systems where we don't want to run unsigned priviliged code. So yes, it works as of today, but at some point of time we shall have to close this hole. Thanks Vivek Signatures kernel modules in general good for support reason. We can say for example that we support only signed kernel and signed modules for that kernel, so we are sure that this binaries match our source. But what is the reason of checking signatures in kexec? If you have root privileges then more likely you have access to boot loader or to physical machine (console, bios). Might be useful only for embedded things to prevent enthusiasts play with already manufactured devices. The way I understand is that we don't allow any unsigned code to run at priviliged level. That's why early from boot everything is signed, that includes shim, bootloader, kernel and modules. User space code does not run with privilige, so it is let run without being signed. Why do it, matthew has explained here in his blog. http://mjg59.dreamwidth.org/9844.html Thanks Vivek ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
