8

A while ago, I had to disable Secure Boot in UEFI in order to install a third-party driver.

Now that this third-party driver isn't required anymore (due to kernel updates), I have uninstalled it.

Having removed that unsigned driver, I thought it might be a good idea now to enable Secure Boot again. Is it? Or could malware have caused damage in the meantime, e.g. adding new Secure Boot keys, so that Secure Boot is not "secure" anymore after it has been disabled once?

caw
  • 406
  • 1
  • 8
  • 30
  • @ElderGeek Thanks! This question assumes that it is. Otherwise, this question is futile, of course. – caw Nov 21 '16 at 17:58
  • @ElderGeek : Generally it is a matter of opinion in the case of Linux systems. Both ways are more or less secure, so it is up to every user to decide which option to choose. Most important is to select the correct boot loader for making the system bootable when changing the boot version (please see my answer). :) – cl-netbox Nov 21 '16 at 18:45
  • @ElderGeek : That's what I meant - "Re-enabling Secure boot in and of itself doesn't present any additional risk ...", so the user is safe to turn it back on again when he wants to do it. :) – cl-netbox Nov 22 '16 at 07:28
  • @ElderGeek Thanks! The question was not whether "[r]e-enabling Secure boot in and of itself [...] present[s] any additional risk" but rather whether disabling it in the first places presents any security risk that renders re-enabling it later useless (due to potential modifications to keys, etc. done by malware in the meantime). – caw Nov 23 '16 at 00:42
  • @ElderGeek As per https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1401532 the main issue with Secure Boot seems to have been fixed now. That means Secure Boot does not silently fall back to loading unsigned kernels anymore. – caw Apr 08 '17 at 16:40
  • @caw Thank you for bringing my attention to these obsolete comments. Yes, the fix was reported released 30 Mar 2017 17:45:23. I'll clean up these comments now, and update my answer as well. – Elder Geek Apr 08 '17 at 21:32

2 Answers2

8

Yes, you can safely re-enable Secure Boot. It is very unlikely that something has been damaged.
Afterwards change the default boot loader from grubx64.efi to shimx64.efi in BIOS | UEFI.
Otherwise Ubuntu tries to boot with the unsigned boot loader - which of course does not work.
Alternatively you can do it before changing the Secure Boot settings with built-in efibootmgr:

To list the currently active boot loader files - execute this command : sudo efibootmgr -v
Change the boot order by running sudo efibootmgr -o XXXX,YYYY (X,Y = entry number)
In case shimx64.efi is not listed, you can add it by executing (X = disk | Y = EFI partition) :
sudo efibootmgr -c -w -d /dev/sdXY -p 1 -L "ubuntu" -l '\EFI\ubuntu\shimx64.efi

cl-netbox
  • 31,163
  • 7
  • 94
  • 131
  • Thanks for your answer! Do I really have to change the boot loader? I've never touched that setting at all, and running sudo efibootmgr -v tells me that ubuntu HD(1,GPT,...)/File(\EFI\ubuntu\shimx64.efi) is the first entry in the boot order. So shouldn't I be able to switch Secure Boot on and off without changing the boot loader? – caw Nov 21 '16 at 19:27
  • @caw Yes, you can (if it fails to boot you can always turn it off again), but honestly there's no Ubuntu benefit ATM... – Elder Geek Nov 22 '16 at 02:54
  • 1
    @caw : As the output of sudo efibootmgr -v shows that shimx64.efi already is the first entry in the boot order, you don't have to change anything regarding the boot loader when you switch on Secure Boot. :) – cl-netbox Nov 22 '16 at 07:19
1

I wouldn't bother. Re-enabling Secure boot won't improve your Ubuntu security in any measurable way (although if it makes you feel better, I don't perceive any harm in doing so).

If you do want to re-enable it you should subscribe to this bug and wait until the bug is fixed as prior to that you are accomplishing nothing from an Ubuntu perspective.

Edit: The aforementioned bug has been reported fixed as of 30 Mar 2017 17:45:23 in the package grub2 - 2.02~beta3-4ubuntu2

and also in the package grub2-signed - 1.80 as of 04 Apr 2017 10:28:34

The deb file (created for Zesty) is available here. Since you are running Xenial, it might be safest to wait for a package developed specifically for your release (or at the very least create a current backup ) to avoid any unexpected consequences brought about by installing a .deb designed for Zesty on a Xenial system.

Community
  • 1
Elder Geek
  • 36,023
  • 25
  • 98
  • 183
  • Thanks for pointing to the bug report that I should subscribe to. However, I'm a bit confused because you said Secure Boot doesn't improve security in any (measurable) way and is just for a "good feeling". I assume you base that statement on the existence of that bug described in the report. Is that true? So if that bug is fixed, it will provide measurable advantages to security, right? – caw Nov 23 '16 at 00:44
  • What I said was I wouldn't bother as re-enabling it currently won't have the effect you seem to desire. It would seem that if the bug is fixed, loading an unsigned kernel without warning will no longer be a concern. If/when this is the case there are still no guarantees. Nothing can prevent operator error for example, and you are still placing your trust in those who built and signed the kernel. – Elder Geek Nov 23 '16 at 13:57
  • The bug in question has apparently been fixed now: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1401532 That would mean Secure Boot does not silently fall back to loading unsigned kernels anymore. Thus, Secure Boot should be an effective security measure with Ubuntu now. – caw Apr 08 '17 at 16:43
  • @caw Yes, a fix has been released for Zesty. See my updated answer. – Elder Geek Apr 08 '17 at 21:58
  • 1
    There's news again in that issue, this time bad news: The status has been reverted from "Fix Released" to "Triaged", which is explained here. A little messy! – caw Apr 11 '17 at 01:45
  • @caw Sounds like a good reason once again, to not bother with it, doesn't it? – Elder Geek Apr 11 '17 at 12:21