https://bugzilla.novell.com/show_bug.cgi?id=842144 https://bugzilla.novell.com/show_bug.cgi?id=842144#c2 Andrey Borzenkov <arvidjaar@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |arvidjaar@gmail.com --- Comment #2 from Andrey Borzenkov <arvidjaar@gmail.com> 2013-09-25 05:20:24 UTC --- I would not call it enhancement ... rather it sounds like honest security issue. We are providing trusted binary that is able to load arbitrary code WITHOUT ANY SECURITY CHECKS. IOW signed grub.efi should really disable any other loader except linuxefi and secured chainloader. I.e. only those loaders that verify payload via shim should be allowed. Of course, this does not solve the problem of unsigned initrd at all, so it just pushes the problem one level up. But as we are not *executing* it, it strictly speaking is not our (grub) problem. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=842144 https://bugzilla.novell.com/show_bug.cgi?id=842144#c3 --- Comment #3 from Michael Chang <mchang@suse.com> 2013-09-25 08:20:03 UTC --- Yes. Things are like Andrey have explained. The grub2-secureboot-no-insmod-on-sb.patch is ineffective as it only blocks insmod command, but still allow module autoloading (which you're using to cheat) and normal.mod which silently loads module .. Recent grub2-secureboot-no-insmod-on-sb.patch has been refreshed and your trick will no longer work for new factory installation. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=842144 https://bugzilla.novell.com/show_bug.cgi?id=842144#c5 Neil Rickert <nrickert@ameritech.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Enhancement |Normal --- Comment #5 from Neil Rickert <nrickert@ameritech.net> 2013-09-25 13:42:44 UTC ---

Neil, which exact version of grub2 do you have?

That trick was with the grub2-efi from 12.3. I can't get the grub from 13.1 to do anything unless I disable secure-boot. In "insmod" really disabled -- perhaps that's part of the problem. In my opinion, it should be checking the validity of insmod loads (either a signature verification or file hash check from a compiled-in list of hashes). I note that the entry to start Windows uses some "insmod" lines. I am not sure to what extent UUID searches depend on "insmod", but if they do then that could also pose a problem with blocking "insmod". I cannot rely on lines such as "set root='hd0,gpt1'". That particular one probably works. But the BIOS hard disk numbering on my box depends on whether a USB disk is plugged in. And on the first boot after install from a USB, there is likely to be a USB flash drive plugged in.

I would not call it enhancement

I'll see if I can change that. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=842144 https://bugzilla.novell.com/show_bug.cgi?id=842144#c7 --- Comment #7 from Michael Chang <mchang@suse.com> 2013-09-27 07:14:04 UTC --- (In reply to comment #6)

Current grub2 supports (mandatory) signature verification. Minor details are key management and what to do with volatile files (grub.cfg, grubenv and similar) :) But this better is discussed in feature request.

IT be a rather big topic. :) I can imagine two of them here .. :) 1. shim might have to offer MOKx to blacklist MOK or hash of binary, therefore if we fix or improve any vulnerability in bootloader (like this case), then it's possible to have a new cert and blacklist the old one (there's seems to be progress or directing on this in upstream shim ..). 2. grub2 is possible to load signed module and signed grubenv file. Well, as long as grub2 only accept gpg signing keys and tools I don't know how can it be integrated to MOK keyrings and probably potential license issues on different crypto implementations etc (openssl/gpg/nss). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=842144 https://bugzilla.novell.com/show_bug.cgi?id=842144#c9 Neil Rickert <nrickert@ameritech.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |INVALID --- Comment #9 from Neil Rickert <nrickert@ameritech.net> 2013-11-30 23:32:42 UTC --- As requested, I am now marking this closed. The released 13.1 does fix the problem of being able to avoid kernel signature check. There is still no check of the integrity of the "initrd" used, and I consider that a weakness of secure-boot. But that's more a limitation than a bug. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.