Secure Boot

I would love to see y'all implement secure boot. Believe it or not it is a rather great piece of security.

1 Like

no it is not, it can be circumvented ridiculously easily. also, why should manjaro pay for a signature and have the hassle of signing everything? this crops up fairly regularly from new users so please search the forum and you will find out why it's not likely to happen any time soon.

8 Likes

Actually, it's not. As a security precaution, it has already been cracked, and the only reason why it was pushed into the UEFI specification was so as to proprietarize what had up until then been an open hardware platform.

Apple sells computers with a preinstalled operating system that was specifically designed for that hardware. Microsoft had no such thing, and being on the UEFI committee, they pushed Secure Boot ─ or more appropriately called, Restricted Boot ─ into the UEFI specification, so as to prevent machines that come with with an OEM version of Microsoft Windows preinstalled from running GNU/Linux.

7 Likes

That was discussed a lot already have a look:

8 Likes

Indeed, and both the other two users are spreading baseless FUD which I'm just too tired tonight to address.

Oh yeah, one day they woke up and decided to prohibit running Linux (yeah, specifically Linux) on all PCs, because, you know, Linux desktop market share was so close to real competition and domination (almost 40%!), they just couldn't let it go on this way any longer. Darn M$!

There's no hassle even with end user manual implementation via custom pacman hooks. On a distro-level, properly written scripts handle signing without user intervention and acknowledgement, somewhere in the background of upgrading. Ubuntu, Fedora, SUSE managed to do that, even Debian has done it recently (and eventually).
Arch, of course, has it's own way.

2 Likes

There is a good commentary about secure boot in the Rufus FAQ section
github.com/pbatard/rufus/wiki/FAQ#Why_do_I_need_to_disable_Secure_Boot_to_use_UEFINTFS

as @Aragorn mentioned, main reason is due to this:

Microsoft-UEFI-CA-Signing-policy-updates
4. Code submitted for UEFI signing must not be subject to GPLv3 or any license that purports to give someone the right to demand authorization keys to be able to install modified forms of the code on a device. Code that is subject to such a license that has already been signed might have that signature revoked. For example, GRUB 2 is licensed under GPLv3 and won’t be signed.

Microsoft hired the security guy at the door
the doorman does not allow anyone in with GPL boots on

6 Likes

exactly, that rufus faq says it all. It's not FUD, it is a reality and has been since 2011.

In the years since then many more exploits have been found and patched but it's like hosing down a smouldering fire. Microsoft manage quite well to keep the majority out of news about it out of the press but I know for a fact it is an ongoing problem. The cycle keeps repeating and always will because hackers with good or bad intentions will always find more exploits.

The problem lies with badly implemented UEFI that allow a number of exploits including some that can be run at user level to get around enabled secureboot 'protection'.

You have to remember that even if manufacturers release firmware updates to close these vulnerabilities, a large number of users will never apply them. This is either because they don't know to apply them and wouldn't know where to start, or because if a machine is running fine they don't care about flashing firmware updates.

Yes, they all got a shim approved by Microsoft. I'm not on about end users handling signing kernels and modules, that's done by the maintainers who would have to provide a shim with a signature that matched. I guess it may have to happen for manjaro-solid at some point but it's all really smoke and mirrors. Secureboot is a misleading marketing term at best and the feature is not a security measure that should be blindly trusted and never will be secure.

The traditional linux method of checking PGP signature for packages and also SHA strings for downloaded ISO is just as good if not better.

9 Likes

Funny thing is how any info that is not coming from Microsoft it's labeled as FUD by some users around here. I don't get this, since when did MS ever become a trustworthy source for info on anything to do with Linux.

Yes, there ARE some Linux distro's using Microsoft's Restricted Boot. Not coincidentally, they are all commercial distributions. There is zero benefit for Linux distro's targeted at home desktop users to implement SB. It is simply a feature that benefits commercial enterpise users and proprietary OS's (not home users).

8 Likes

On some systems you can customize secure boot by enrolling the grub binary - just point the system firmware to it.

No need for Manjaro to buy into a Microsoft certificate chain - that would create dependency on Microsoft.

8 Likes

Explain. Details. Links.
If we multiboot from a shim grub to a non-shim efi file, that will still bypass secure boot.
Perhaps you are saying something else?

A Clevo N141WU

I have never played with it - but it is obviously a possibility in this particular firmware.

In a ThinkPad T550 Secure boot offers an option to enroll own certificate and keys.

I have also found that on some systems you can disable secure boot - install your Manjaro - and enable secure boot. This allows the system to be locked down using a password on the firmware to block others from disabling secure boot - but allows Manjaro to boot - I think simply because it is there (not blocked from being run or installed - as secure boot was disabled at install time) and secure boot thinks - this must be OK.

Secure boot is only as secure as the user running the system.

Some vendors has made it hard to get to the firmware by removing any hints on how to do it - even removed the usual hotkey - on unknown systems a systematic test of function keys and other possible keys will often reveal itself.

On some Lenovo systems you need to find a pinhole - and while the system is shutdown - press the button behind the pinhole with paperclip - and viola - you are in the firmware.

My guess is that this should help secure the system but if the firmware is not password protected - so what?

Of other obscure attempts to hide secure boot is the need of an enabled firmware password before secure boot options become available - on some systems even to be able override boot priority.

6 Likes

That's totally another thing... Absolutely irrelevant. It's like saying that disk encryption can save you from an attack over the internet. But it's good at its place, of course.

1 Like

Thanks @linux-aarhus
Haven't seen a bios-setup like this.

Your first screen shot shows you can 'enroll a efi image'.
Have you tried enrolling an OS efi in it?
Like grub.efi, boot.efi or perhaps even a core.efi (in /boot/grub/).
Perhaps this can set an entry in the bios firmware and perhaps in efibootmgr?
That will be neat (nice). :smile:

The second screen shot lets you set your own PUK key?
Then I wonder how you can tie in that key with our 'ordinary' grub - maybe the method how linux OS shim use Microsoft PUK keys, which I haven't found out, or want to find out).
But if you can add more what you know, that will be good. But if don't know, it's okay, no need to find out just for us. We're not going to use it, :laughing:, just for our knowledge.

Thanks again. Appreciate it. Cheers.

I have never tried - not enough incentive - or to much digging - I don't know - maybe I will get to it.

At the moment my twin brain cells are playing ping-pong on

1 Like

no it's not at all what I meant. i'm saying that packages and ISO images signed by manjaro developers are equally good protection to secure boot which cannot alone fully protect from an attack over the internet either, the vulnerabilities are far greater than a single boot signature can ever plug. even if you choose WHQL only mode in EFI, you can still over-ride that with the boot option to disable driver enforcement offered by Windows.

all secureboot does is look for a certificate upon boot and prevent booting without one. that certificate checking is rendered useless by the fact you can add a custom PUK key (necessary evil but it's where the vulnerability lies in the affected EFI firmware that's not been patched, the EFI capsule is always unlocked in those), also turn off signed driver enforcement anyway which is checked by the OS rather than EFI (which any attacker can code their infected code to do).

therefore the argument that secureboot is pointless is very strong.

1 Like

Okay, I probably won't too, if I were you. Just unnecessary 'features'. :rofl:
Just saw your encryption topic. I have the same thought (unnecessary features) - a plain encrypted data partition seems sufficient enough but to each his/her own.

Cheers.

3 Likes

Just adding to what you said.
What 'exploits' do we need to boot a 'secureboot' OS? Either Windows or Linux.
From another 'simple grub' or from any install media grub, we don't need any 'exploits' to go into it.

As said elsewhere, it is like putting a fancy padlock on a 1 meter fence.
And as said then, and the main point, using and defending microsoft's keys on our own OS is like defending our neighbour's locking our own house or ..... our own rapist. :rofl: Hor! Hor! Hor!!!!

2 Likes

From my experience - no exploits is needed - just access to the unprotected firmware

3 Likes

that metaphor cracked me up but i hope it doesn't land you in hot water with more sensitive types.

windows speak for the backdoors left open and used to circumvent this chocolate fireguard feature. linux users and windows users as well for that matter don't need to use the 'exploits' at all, just a keyboard and finger (or a paperclip too sometimes). the mostly OEM software with exploitable features (but also windows kernel itself has been patched a few times to counter this) resides solely in the windows domain and has supposedly been patched but like I said, repeatedly they find new holes.

2 Likes

Forum kindly sponsored by