35

On initial installation of Ubuntu 16.04, I checked off "Install third-party software" and, underneath it, I was prompted to check off another option which would allow the OS package to automatically disable secure boot on its own, a prerequisite of which was creating a password that would somehow allow this whole process to occur.

After continuing with the installation, I was never given any indication that this disabling of secure boot had occurred, nor was I ever prompted to enter the password that I had created.

Upon successful installation of the OS, I restarted my computer and checked out the BIOS. In BIOS, secure boot was still enabled. However, back in Ubuntu, I am able to seamlessly play MP3 and Flash files, which I assume indicates that the installation of third-party software was successful.

I haven't run into any problems as of yet (other than the fact that the UI has been a bit finicky and buggy at times), but I would like to know what on Earth I actually accomplished by creating that password.

What happened to the password I created? Will I need to remember it for any reason? It's not the same as my login/sudo password.

Has Ubuntu permanently edited my BIOS in order to make an exception for itself? If so, how can I view these changes and potentially undo them? Is that where the password would come in?

Why does Ubuntu need to disable/bypass secure boot to install the ubuntu-restricted-extras package anyway? Is my installation okay? Have I set myself up for future problems? Should I try reinstalling with secure boot manually disabled as not to receive that prompt in the first place?

Additional information: I am running a UEFI system, and I am dual-booting Ubuntu 16.04 alongside Windows 10.

Another user has asked a question about a similar problem here. Unlike this user, I do not receive a warning about "booting in insecure mode," but I would also like to know whether Ubuntu has created an exception for itself and how I could manage such exceptions. Unlike myself, this user has not mentioned anything about having to create a password.

I managed to replicate the dialogue box. Here it is.

Here's some additional information.

Improve this question
7
  • 1
    Ubuntu 16.04 has made some changes to its handling of Secure Boot that I have yet to fully explore myself; however, some of what I do know is in my answer to this question. I'd be interested to see your output to the command hexdump /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c. The last digit on the first line (0 or 1) indicates your Secure Boot status (inactive or active).
    – Rod Smith
    May 1, 2016 at 16:42
  • 1
    0000000 0006 0000 0001 0000005 Looks like it's definitely active. Note that I have disabled and re-enabled it a couple of times to see if anything would happen, and nothing did. Again, everything's running fine so far, my only fear is that something might go wrong sometime in the future. After reading some documentation, it seems that the temporary password is meant to act as a sort of surrogate for secure boot rather than Ubuntu directly supporting the feature itself. Considering I was never asked for it again, my best guess is that the feature is incomplete/bugged.
    – Cosmo
    May 4, 2016 at 19:16
  • 1
    Just a heads-up, I might be wrong about the temporary password being a surrogate for secure boot. That's just all I can understand it as being without additional information, which I've been unable to find. What do you think?
    – Cosmo
    May 4, 2016 at 19:39
  • 1
    I'm afraid I don't have further thoughts on this issue. It will take some time and effort for me to investigate these recent changes.
    – Rod Smith
    May 5, 2016 at 12:57
  • 1
    Secure boot requires a password, it can't be blank and needs some kind of authentication. This is why network administrators will leave secured computer systems with no password for the admin account, because you can't remotely login without a password.
    – Delorean
    Aug 8, 2016 at 19:47

1 Answer 1

Reset to default
12

UEFI Secure Boot protects your boot loader from being tampered with by using a combination of CA keys and signatures in boot files. Microsoft for example has signed boot loaders for which CA keys are already present in UEFI firmware of most PC's already.

This only protects the very early core of the loader and nothing afterwards. For example initrd(initramfs) is not protected, or anything after (GRUB, kernel, Modules, Drivers, anything in userspace, etc).

3rd party software that you installed MAY have included certain low-level PCI or RAID code required for the boot loader, which is why you need to create a password, which will create a key in the UEFI firmware's space. After modifications, if the system notices something different at boot time, the BIOS will stop at POST and ask for the same password you entered during installation to prove that you are the one who installed the software. This method insures that a user physically sitting at the computer is entering this password as confirmation since no software can be loaded at BIOS POST time to fake this.

For most user systems, secure boot does little to protect you. It does not prevent viruses or malware, or installation of those. All it does it prevent low-level bootloader tampering, which is usually prevented by basic antivirus or OS security anyways. In my opinion, and according to most documentation out there, it can be safely disabled.

Improve this answer
6
  • This sounds like it might be the answer I'm looking for! So despite creating a password, I may never be asked for it unless I make modifications to my BIOS?
    – Cosmo
    Aug 23, 2016 at 15:28
  • 1
    Not quite. You may be asked for it if you install something that modifies the boot loader, which is what the UEFI firmware checks for at every bootup and compares those files' signatures to stored keys in its database.
    – Delorean
    Aug 24, 2016 at 16:11
  • 1
    Don't you mean, "for most kinds of attacks, secure boot does little to protect you?"
    – jpaugh
    Aug 31, 2016 at 0:41
  • 1
    @jpaugh You could use the word attack I guess. However, most infections/viruses/malware are not considered a direct attack as usually these things are just set out in the wild to infect and spread to everyone, and nobody in particular. But yes, someone gaining access to your system remotely and trying to mess with your boot would be considered an attack.
    – Delorean
    Aug 31, 2016 at 18:24
  • 1
    @Cosmo grub commands shouldn't set it off since this runs in memory after grub has already been loaded. But perhaps the command you're running is trying to run a module that didn't run before, which is setting off the UEFI alarms... Are you just being prompted for a password from your BIOS? If you disable secure boot in the BIOS does it run with no prompt?
    – Delorean
    Aug 31, 2016 at 18:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .