Re: [RFC] Kdump with signed images
On Wed, Oct 24, 2012 at 10:43 PM, 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 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: Kdump with signed images
On Wed, 2012-10-24 at 13:36 -0400, Vivek Goyal wrote: > On Tue, Oct 23, 2012 at 09:19:27AM -0700, Eric W. Biederman wrote: > > Vivek Goyal writes: > > > > > On Tue, Oct 23, 2012 at 09:18:54AM -0400, Vivek Goyal wrote: > > > > > > [..] > > >> > >> There are 3 options for trusting /sbin/kexec. There are IMA and > > >> > >> EMA, > > >> > >> and it is conceivable to have ELF note sections with signatures for > > >> > >> executables. > > >> > > > > >> > > Can you please tell more about what is EMA and IMA. I did quick > > >> > > google > > >> > > and could not find much. > > >> > > > >> > That should have been EVM and IMA. Look under security/integrity/. I > > >> > don't know much about them but they appear to be security modules with > > >> > a > > >> > focus on verifying checksum or perhaps encrypted hashes of executables > > >> > are consistent. > > >> > > >> I will do some quick search there and I see if I can understand > > >> something. > > >> > > > > > > Ok, I quickly went through following paper. > > > > > > http://mirror.transact.net.au/sourceforge/l/project/li/linux-ima/linux-ima/Integrity_overview.pdf > > > > > > So it looks like that IMA can store the hashes of files and at execute > > > time ensure those hashes are unchanged to protect against the possibility > > > of modification of files. IMA-appraisal originally was hashed based, but Dmitry Kasatkin added digital signature support. Both have been upstreamed. > > > 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. Assuming the IMA policy syntax is updated to require 'security.ima' to contain a digital signature, then it is only a question of protecting the _ima and _evm keyrings. (Dmitry has such a patch waiting to be reviewed.) So the new program would have to be vetted by someone trusted. > > > Whole idea behind UEFI secure boot seems to be that all signing happens > > > outside the running system and now only signed code can run with higher > > > priviliges. > > > > No. UEFI secure boot has absolutely nothing todo with this. > > > > UEFI secure boot is about not being able to hijack the code EFI runs > > directly. Full stop. > > > > Some people would like to implment a security policy that says > > you can't boot an untrusted version of windows from linux if you have > > booted with UEFI secure boot, so they don't get their bootloader > > signatures revoked by microsoft. > > > > A security model relying on Microsoft's key is totally uniteresting to > > me. Either signing at the UEFI level is of no use or Microsofts key > > will fall again to the combined assult of every cracker and every > > governmental dirty cyber ops division attacking it. Not to mention that > > Microsoft has little incentive to keep linux booting. > > > > I think it is reasonable to be able to support a policy where we can't > > boot unsigned versions of Microsoft windows. However beyond being able > > to exclude booting windows being one criteria for our policy mechanism > > please don't even start to justify things with that ridiculous security > > policy even indirectly. > > > > > IMA seems to be only protecting against only making sure > > > existing binaries are not modifed but it does not seem to prevent against > > > installation of new binaries and these binaries take advantage of kexec > > > system call to load an unsigned kernel. The IMA/IMA-appraisal policy dictates what needs to be appraised. The default ima-appraisal policy appraises all files owned by root. > > I believe you can combine IMA with EVM signed security attributes where > > the EVM signing key is offline, and the verification key is in the > > kernel. > > > > The combination of IMA and EVM gets very close to being able to sign > > executables offline and be able to update them. > > [ Again CCing lkml and IMA/EVM folks ] > > After little reading, my understanding is EVM also does not support > offline signing. > > http://sourceforge.net/apps/mediawiki/linux-ima/index.php?title=Main_Page > > Given the fact EVM protects IMA data (security.ima), which is generated > inline, I am not sure how EVM can sign images offline. > > I might have misunderstood things, please correct me if that's not the > case. > > Thanks > Vivek > IMA-appraisal verifies the integrity of file data, while EVM verifies the integrity of the file metadata, such as LSM and IMA-appraisal labels. Both 'security.ima' and 'security.evm' can contain digital signatures. thanks, Mimi ___ 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 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: cyclic makedumpfile
Hello Cliff, On Tue, 23 Oct 2012 17:51:05 -0500 Cliff Wickman wrote: > Hello Mr. Kumagai, > > I was looking for some information about the "cyclic" processing in > makedumpfile, and came upon this: > http://lists.infradead.org/pipermail/kexec/2012-July/006480.html > That's why I'm sending this question to you. Thank you for your suggestion for improvement. > I work on the Linux kernel here at SGI. We are trying to dump some very > large memories, and so we are very interested in this cyclic feature. > > I built makedumpfile-1.5.0 and tried it out. > It seems to work fine, but does spend a lot of time building bitmaps. > > If I set the cyclic-buffer value to create 3 cycles, then > exclude_unneccessary_pages_cyclic() is entered 6 times: > - 3 times from get_num_dumpable_cyclic() (via update_region_cyclic()) > - 3 times from write_kdump_pages_and_bitmap_cyclic() > (also via update_region_cyclic()) > > These page structure scans of /proc/vmcore for terabytes of memory can > take a long time, and so I think something might be done to remove the > redundant scans. > > Could it not be possible to save the bitmaps created during the > get_num_dumpable_cyclic() pass? And then retrieve them for the > write_kdump_pages_and_bitmap_cyclic() pass? I think this could save > literally hours on a very large memory. > > Perhaps they could be written to a file, or files. makedumpfile should work also on the environment which doesn't mount a root filesystem when 2nd-kernel is running. In such environments, writing to a file isn't the solution because the bitmap file is created on 2nd-kernel's memory. This is the starting point of our discussion. Therefore, we can save only a chunk of bitmap at a time, so we have to scan each region twice. > But I'm sure you understand the logic of makedumpfile much better than I. > Do you think such an enhancement is possible? > Or perhaps you already have another workaround? Now, I plan to do the two enhancement for performance, please see below. in v1.5.1: - Minimaize the number of cycle http://lists.infradead.org/pipermail/kexec/2012-October/006864.html in v1.5.2: - Improve the filtering logic http://lists.infradead.org/pipermail/kexec/2012-June/006441.html Thanks Atsushi Kumagai > > Thanks much. > -Cliff Wickman ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: Kdump with signed images
On Tue, Oct 23, 2012 at 09:19:27AM -0700, Eric W. Biederman wrote: > Vivek Goyal writes: > > > On Tue, Oct 23, 2012 at 09:18:54AM -0400, Vivek Goyal wrote: > > > > [..] > >> > >> There are 3 options for trusting /sbin/kexec. There are IMA and EMA, > >> > >> and it is conceivable to have ELF note sections with signatures for > >> > >> executables. > >> > > > >> > > Can you please tell more about what is EMA and IMA. I did quick google > >> > > and could not find much. > >> > > >> > That should have been EVM and IMA. Look under security/integrity/. I > >> > don't know much about them but they appear to be security modules with a > >> > focus on verifying checksum or perhaps encrypted hashes of executables > >> > are consistent. > >> > >> I will do some quick search there and I see if I can understand something. > >> > > > > Ok, I quickly went through following paper. > > > > http://mirror.transact.net.au/sourceforge/l/project/li/linux-ima/linux-ima/Integrity_overview.pdf > > > > So it looks like that IMA can store the hashes of files and at execute > > time ensure those hashes are unchanged to protect against the possibility > > of modification of files. > > > > 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. > > > > Whole idea behind UEFI secure boot seems to be that all signing happens > > outside the running system and now only signed code can run with higher > > priviliges. > > No. UEFI secure boot has absolutely nothing todo with this. > > UEFI secure boot is about not being able to hijack the code EFI runs > directly. Full stop. > > Some people would like to implment a security policy that says > you can't boot an untrusted version of windows from linux if you have > booted with UEFI secure boot, so they don't get their bootloader > signatures revoked by microsoft. > > A security model relying on Microsoft's key is totally uniteresting to > me. Either signing at the UEFI level is of no use or Microsofts key > will fall again to the combined assult of every cracker and every > governmental dirty cyber ops division attacking it. Not to mention that > Microsoft has little incentive to keep linux booting. > > I think it is reasonable to be able to support a policy where we can't > boot unsigned versions of Microsoft windows. However beyond being able > to exclude booting windows being one criteria for our policy mechanism > please don't even start to justify things with that ridiculous security > policy even indirectly. > > > IMA seems to be only protecting against only making sure > > existing binaries are not modifed but it does not seem to prevent against > > installation of new binaries and these binaries take advantage of kexec > > system call to load an unsigned kernel. > > I believe you can combine IMA with EVM signed security attributes where > the EVM signing key is offline, and the verification key is in the > kernel. > > The combination of IMA and EVM gets very close to being able to sign > executables offline and be able to update them. [ Again CCing lkml and IMA/EVM folks ] After little reading, my understanding is EVM also does not support offline signing. http://sourceforge.net/apps/mediawiki/linux-ima/index.php?title=Main_Page Given the fact EVM protects IMA data (security.ima), which is generated inline, I am not sure how EVM can sign images offline. I might have misunderstood things, please correct me if that's not the case. 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 09:44:59AM -0700, Eric W. Biederman wrote: > Matthew Garrett 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: makedumpfile 1.5.0 takes much more time to dump
Hello Lisa, On Mon, 22 Oct 2012 07:20:18 -0600 Lisa Mitchell wrote: > Jerry Hoemann and I tested the new makedumpfile 1.5.0 on a DL980 with 4 > TB of memory, which is the maximum supported for this system. We tested > it on top of a 2.6.32 kernel plus patches, had the dump level set to 31 > for smallest dump, and found that the dump would not complete in a > reasonable time frame, basically staying for over 16 hours in the state > where it cycled through "Excluding Free pages" (would go from 0-100%) > and "Excluding unnecessary pages" (0-100%). It just alternated between > these two all night. I did not try waiting longer than 17 hours to see > if it ever completed, because with an earlier makedumpfile on this same > system, the dump would complete in a few hours. Console logs can be > provided if desired. > > Are we are seeing known issues that will be addressed in the next > makedumpfile? > > >From this email chain, it sounds like others see similar issues, but we > want to be sure we are not seeing something different. I think you're seeing the known issue which we discussed, I will address it in v1.5.1 and v1.5.2. > I can arrange for access to a DL980 with 4 TB of memory later when the > new makedumpfile v1.5.1 is available, and we would very much like to > test any fixes on our 4 TB system. Please let me know when it is > available to try. I will release the next version by the end of this year. If you need some workarounds now, please use the workaroud described in the release note: http://lists.infradead.org/pipermail/kexec/2012-September/006768.html At least in v1.5.0, if you feel the cyclic mode is slow, you can try 2 workaronds: 1. Use old running mode with "--non-cyclic" option. 2. Decrease the number of cycles by increasing BUFSIZE_CYCLIC with "--cyclic-buffer" option. Please refer to the manual page for how to use these options. > Meanwhile, if there are debug steps we could take to better understand > the performance issue, and help get this new solution working (so dumps > can scale to larger memory, and we can keep crashkernel size limited to > 384 MB), please let me know. At first, the behavior of makedumpfile can be described as two steps: Step1. analysis Analyzing vmcore and creating the bitmap which represent whether each pages should be excluded or not. v1.4.4 or before save the bitmap into a file and it grows with the size of vmcore, while v1.5.0 saves it in memory and the size of it is constant based on BUFSIZE_CYCLIC parameter. The bitmap is the biggest memory footprint and that's why v1.5.0 can work in constant memory space. Step2. writing Writing each pages to a disk according to the bitmap created in step1. Second, I show the process image below: a. v1.4.4 or before [process image] cycle 1 +- -+ vmcore| ... | +- -+ [execution sequence] cycle | 1 -+--- step1 | 1 | step2 | 2 [bitmap] Save the bitmap for the whole of vmcore at a time. b. v1.5.0 [process image] cycle 1 2 3 4...N +- -+ vmcore| | | | | ... | | +- -+ [execution sequence] cycle | 1 2 3 4... N -+ step1 | 1 /3 /5 /7 / (2N-1) | | / | / | / | / | step2 | 2/ 4/ 6/ 8/ (2N) [bitmap] Save the bitmap only for a cycle at a time. Step1 should scan only the constant region of vmcore correspond to each cycle, but the current logic needs to scan all free pages every cycle. To sum it up, the more the number of cycle, the more redundant scans will be done. The default BUFSIZE_CYCLIC of v1.5.0 is too small for terabytes of memory, the number of cycle will be so large. (e.g. N is 32 in 1TB machines.) As a result, a lot of time will be spend for step1. Therefore, I will implement the feature to reduce the number of cycle as few as possible automatically in v1.5.1. Now, you can get the same benefit by allocating enough memory with --cyclic-buffer option. For 4TB machines, you should specify "--cyclic-buffer 131072" if it's possible. (In this case, 256MB is required actually. Please see the man page for the details of this option.) Additionally, I will resolve the issue included in the logic of excluding free pages in v1.5.2. Thanks Atsushi Kumagai ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
