Sounds like the same anti competitive behavior that MS was punished for two decades ago. Making it a requirement to only boot software approved by them excludes a whole range of competitors from using the same hardware. Making that a condition for OEMs to even get a license is the problem here.
Lenovo is otherwise known for supporting Linux on their laptops. And yes I know you can jump through hoops and fiddle with scary (for ordinary users) bios options to "fix" this. The point is that you shouldn't have to and this is a bit too convenient for MS to keep competitors off laptops.
Basically, what is needed here is a neutral certificate authority not controlled by a single company with a reasonable process for independent operating systems to get a certificate.
I recently ran into this trying to boot linux on my old imac. Ubuntu actually works but forget about arch, manjaro, and a whole lot of other distributions. Imacs have no off-switch for secure boot that I know off.
Not disagreeing with the general message, but IMHO if a user is willing to go through the hassle of installing another OS, as easy as it is nowadays, I don't think toggling a bios option is _that_ big of a deal.
As far as I'm concerned as long as it's possible to re-enable the 3rd Party CA (or disable Secure Boot altogether) it's not tragic considering this only applies to a specific kind of machines ("Secured Core PCs") and not to mainstream ones
> if a user is willing to go through the hassle of installing another OS, as easy as it is nowadays, I don't think toggling a bios option is _that_ big of a deal.
It is trivially easy to boot from a USB pendrive; most computers will do it by default if there's no preinstalled OS, many devices have a hotkey you can press/hold which redirects towards booting from USB, and even Windows itself will outright let you do it from the Settings app. You don't even have to interact with the system firmware setup program.
On the other hand, disabling secure boot (or taking ownership of it) is designed to be as difficult as possible, intentionally. Many vendors will actually have a Scary Boot Prompt or the like which makes you double-acknowledge when you change Secure Boot settings, and even reminds you (on every boot) that you have Secure Boot disabled.
It is also unfair by itself that MS OSes will boot without requiring the user to fiddle with the system firmware, but non-MS OSes won't. This puts a glass ceiling on non-MS operating systems regarding how easy their setup flow can be.
> It is also unfair by itself that MS OSes will boot without requiring the user to fiddle with the system firmware, but non-MS OSes won't
Unfair? You're talking about systems that come with Windows pre-installed. Of course these systems are going to be configured for booting Windows out of the box.
>> It is also unfair by itself that MS OSes will boot without requiring the user to fiddle with the system firmware, but non-MS OSes won't
>Unfair? You're talking about systems that come with Windows pre-installed. Of course these systems are going to be configured for booting Windows out of the box.
I think it more _accurate_ to have said "of course these systems are going to be configured to boot nothing but Windows out of the box", which is ... drum roll please.. anti-competitive. Facially, and blatantly anti-competitive.
You're correct of course. Fair would be you can return the license to microsoft on purchase and claim the entire value of your refund. Microsoft have been engaging in the clearest anti-competitive behaviour for decades and it is grossly unfair on consumers, competitors and the industry as a whole.
We really must not conflate "predictable behaviour" or "established behaviour" with "acceptable behaviour" in any part of life including corporate crime.
.. first read through all these comments here, but I see no mention of MSFT commercially inserting Canonical OS products into desktop windows, with extra features added to Ubuntu to restrict and control the internals.. examples are partition type msft-private and msft-data; secretive systemd components; secretive vmx flag use; boot signing and signed applications; snapd container for libssh with auto-updates required to be on.. and more?
There's a difference between stick in a usb key to fiddle with bios in vendor specific way and then stick a usb key in. It's an extra hurdle.
If your instructions read: "turn off secure boot", MS has already won. Some users will, most won't, and many company IT departments would not allow you to on principle (because it's company hardware and they want it secured because it is their problem if it isn't).
This is an extremely weird argument. So called Live CDs come from an era where CD drives were ubiquitous and even back then installing an OS (provided you did not want to install two OSes at the same time) was as simple as installing any other piece of software. If anything, with all these secure boot shenanigans it requires more skill to install an OS than when a smartphone was not even a thing. This argument advocates for walled-garden IT. This argument used in support of restrictions under the hood arguments for IT stuff to be hard in principle.
Yes, the removal of CD/DVD-drives is as much of an obstacle to installing Linux as having to toggle a setting on a Windows-preinstalled machine that someone bought. You are also free to buy a SKU that doesn't come with a Windows license and Windows preinstallation.
Also please keep in mind that it's not Secure Boot you have to disable, it's a CA you have to re-enable on machines that came with Device Guard pre-enabled.
You miss the entirety of the point. Today you have a USB drive, nothing stops SOHO routers by default starting PXE server with latest distros which would be even easier to use. This is an artificial obstacle.
You keep arguing all over the place that this is an insignificant obstacle, but do not address the very core of the debate: whether only MS keys being installed by default is for security purposes in the first place and whether it does actually increase security. We are not arguing how many hoops to install Linux (or whatever) is too much. we are arguing whether certain OSes should be easier to install at all.
Don't bring it up as an obstacle if it's not an obstacle, that you're instead concerned about Microsoft's keys.
In that case though, it's not "only MS keys" really, it's not enabling one CA. In the end if there's a strong need, Canonical, Red Hat or the likes could start building their own CA and negotiate it to be included, would be very fair and probably wouldn't be affected by this toggle. But they do not seem interested however in the much easier MS UEFI CA-signed Secure Boot, Ubuntu does it fine, but Fedora can't sign DKMS modules and the rest are even worse.
So the thing is, the problem of "trust" is very complex and putting in the work is very expensive. Microsoft has chosen to do this to improve their customers' security, they offer others the opportunity to participate and few are actually willing. That's not their fault really.
In the end they'd get slapped so hard by antitrust if they ever truly removed that toggle and the option to run other software. (Unlike Apple or other mobile vendors, who can do whatever they wish, with no such uproar over what is way worse than the toggle discussed here.)
> Hurdle that doesn't matter at all. If you have the skillset to install an OS, changing a setting in UEFI is nothing.
That assertion is a bit too absolute; I am comfortable installing an OS using the USB installer because I have done it many times. I haven't had to change UEFI settings yet and I'm worried that doing something wrong will lock me out (in case of a botched OS install, I can just start over).
What matters more in this instance is the rhetoric and messaging being used. Microsoft is using "Secure-core" as a measurement and indicator of security posture while at the same time installing a Linux-based system somehow detracts from that objective. It's not just a matter of technical ability. Organizations and people, in general, will be exposed to this, which is simply not true. For enterprise IT, this will also mean that by default, they will need to justify alternatives, creating extra friction for competing solutions.
> Microsoft is using "Secure-core" as a measurement and indicator of security posture while at the same time installing a Linux-based system somehow detracts from that objective
If you read what Secured Core or even Device Guard consists of, Linux actually does detract from it. I use Linux daily on all my machines, I have no sympathy towards Windows at all, but Linux has certainly fallen behind in some aspects - boot integrity and boot anti-tampering is one of those aspects. And that's not all Secured Core provides in the end.
Linux has fallen behind in boot security and anti-tampering because all of the solutions in this area are proprietary and at least initially released under NDA. You're using the effects of this very program to justify itself.
Firstly, it wasn't a justification, it was a description of the current state.
Secondly, no, they aren't all proprietary. If we start from the bottom then Secure Boot is neither proprietary or NDA'd. There are even open-source implementations of Secure Boot. We simply have a significant amount of feet-dragging and misconceptions out there, pointlessly making using just SB alone difficult and not the default, you can see a bunch of it in this thread as well.
I won't even get into measured boot to auto-unlock FDE/LUKS or god forbid LIM, those aren't difficult because of some supposedly NDA'd specifications. Damn, enabling IOMMU isn't that difficult either. Nobody else should be blamed for the poor state of those.
Lastly, some standard being initially released under NDA or being proprietary (which ones do you actually have in mind?) is a terrible justification to not improve things. Or find alternatives just as good.
> some standard being initially released under NDA or being proprietary (which ones do you actually have in mind?) is a terrible justification to not improve things. Or find alternatives just as good.
I think them being NDA / proprietary is a reason we can't improve things, not a justification for it.
In this case it is an option, you can still disable UEFI Secure Boot, re-enable the UEFI CA and enroll your own keys. The only thing that changes is a default in an option you would need to alter in any case if you wanted to control the boot yourself.
The real problem is lately we've been seeing malware that lives in UEFI from APT (Edit: Advanced Persistent Threat actor, usually state sponsored) groups. That means it is persistent and will typically disallow updating the UEFI once infected. And almost everyone hates OS updates, and the smallest percentage are willing to update firmware, because it can brick a device, so UEFI isn't going to get updated. This is one of the few things you MUST trust, even if you want to follow zero trust.
Firmware should have a physical switch to enable updating it. Fuck self checked signatures. There, fixed all the BIOS and firmware exploits for you. You're welcome.
Firmware vulnerabilities aren't necessarily used to target the firmware or to try to gain persistence - vulnerabilities in SMM handlers, for instance, can be used for privilege escalation at runtime.
Limit, but it doesn't remove all avenues of attack. Firmware config needs to be writable at runtime (things like cold boot attack protection require state to persist over power cycles, even if you don't think other firmware config should be modifiable without physical presence), and the code that parses that could still contain vulnerabilities. Making firmware mostly read-only would mitigate certain classes of attack, but not all of them.
I'm responding to "There, fixed all the BIOS and firmware exploits for you". It doesn't actually fix all the potential exploits, and it makes it more difficult to apply the updates that would be required to fix them.
That only works for IT-managed devices (and even then, is very expensive in terms of labor). Consumer devices need auto-update to protect them from known vulnerabilities. Auto-update is hard to get right, but your product is defective by design if it doesn't support it.
Sometimes firmware updates make the system worse or even completely bricked. If the machine already working and stable, I've learned it's a risky / bad idea to eagerly apply firmware updates.
Flash media is cheap nowadays, and HP EliteBook series laptops store a couple of previous BIOS versions on board to make rollback possible. Also these higher end laptops can try previous version of their firmware if they fail to boot with the latest one.
Failing to see how Lenovo can't implement something like that.
Bad idea because firmware bugs are a growing attack vector and you are leaving yourself exposed to known, easily-exploited vulnerabilities by not staying up to date.
I mean sure, but no one is forcing users to install software from APT groups. That's a choice people make. The general point is that you should be able to use hardware for general computing. There can be a switch that by default limits to software signed by your original manufacturer but that should toggleable by the end user.
OP probably misunderstood it as Advanced Pacakge Tool, the system Debian uses for package management (ie APT sources) instead of Advanced Persistent Threat which is what the quote is talking about (ie sophisticated hackers, usually state backed/state owned that attack your machine).
>I recently ran into this trying to boot linux on my old imac. Ubuntu actually works but forget about arch, manjaro, and a whole lot of other distributions. Imacs have no off-switch for secure boot that I know off.
Does it also not let you use your own keys? Because if it does, you don't have to turn SB off, just use your key to sign the UKI and a bootloader like systemd-boot. It should work with any distro, especially one that uses dracut to create the initramfs because it's a couple of lines of dracut config to generate a (signed) UKI instead.
Not in a way that is obvious to me. I'm sure you can work around it but if you just want to boot a live image and run an installer, ubuntu works and not a whole lot of other distributions do (because their installers don't support secure boot). I assume this is because of how much of a PITA it is to get certified.
>I assume this is because of how much of a PITA it is to get certified.
Distros don't have to do anything distro-specific to get signed. Most distros use (Microsoft-signed) shim to chainload to something like grub.
But yes, it might be that the live CDs don't do that; I don't know. My experience with SB on all my machines has been to start with SB disabled and then I enable it afterwards with my own keys. I know the gparted and OpenSUSE live CDs support SB because I've booted off them after enabling SB.
You could boot the Ubuntu live CD (or something smaller like gparted), mount the other distro's live CD, chroot into it, and run the other distro's installer that way. Just be sure that you enable SB support so that the installation actually boots afterwards.
> Distros don't have to do anything distro-specific to get signed. Most distros use (Microsoft-signed) shim to chainload to something like grub.
You still have to get your own version of shim signed if you want your distro to boot "Scary Boot Prompt"-free. I.e. if you just use RedHat's version of shim, that shim will transparently boot RedHat signed kernels, but refuse to boot SuSE's -- unless you whitelist SuSE's key manually into shim. It's not ideal in any way.
I believe for OpenSUSE it uses MokManager to get the user to trust the OpenSUSE CA. But it's been a while since I tried it so I might be misremembering. (MokManager is broken on my mobo so I switched to systemd-boot + my own signing keys, which is better for security anyway.)
My new Microsoft Surface Book let’s me switch to 3rd party CAs or even none at all, with no problem. This sounds like a Lenovo issue.
On top of that, I would prefer if my machine is by default, in a secure configuration when I buy it. Since the laptops come with Windows pre-installed and Microsoft signed bootloaders, it is fundamentally more secure than if the 3rd parties CAs are enables. I don’t want an attacker chain loading Linux and KVM beneath my Windows OS.
>I don’t want an attacker chain loading Linux and KVM beneath my Windows OS.
If your Windows install was protected by Bitlocker, and the decryption key was stored in the TPM, and the TPM was set up to require attestation to unseal the key, then such chainloading wouldn't be an issue. (This is also explained in the article.)
BTW, the default for the firmware interface is that it is not password-protected, so even this particular Lenovo device is vulnerable to the evil maid attack you're describing in its "default secure configuration", because the maid can just toggle that option to enable the UEFI CA, or even disable SB entirely. Unless Lenovo is planning to make the UEFI password a required step in their purchase order process, you can expect that the default configuration is going to be an unprotected UEFI. That's why the way to resolve the threat is not to prevent other bootloaders, but to prevent them from reading the data on disk.
> It is still an issue. A different OS could load and mimic the normal boot procedure to steel any credentials entered.
What credentials? The bitlocker key is in the TPM. It's not something a human can enter.
>Also, the whole scenario you depict is quite unreasonable to expect of a default install - which is exactly what is being talked about.
I'm confused. Are you referring to the scenario of the Windows install with the bitlocker key in the TPM, or the scenario of the evil maid attack? The former is already how Windows works by default, and the latter is precisely the scenario that helloooooooo was talking about, so I'm not sure which one you're calling unreasonable.
Not really; most people unlock Bitlocker via TPM, that's why a shitton of people don't even realize they have it. If the TPM doesn't give up the key, you are asked for the _recovery key_, not a passphrase.
And the fact they have no clue what the "recovery key" is, that is how most people realize they had Bitlocker on...
MS actually keeps a copy of _your_ PC's recovery key on their servers when you install Windows; that's one of the official reasons they have for requiring a MS account when you set Windows up: so that they can store your recovery key for you and give it back to you if ask nicely. (Moral implications of this best left for another discussion). This is for the personal editions of Windows, in the business editions of Windows; your IT (via ActiveDirectory) will store your recovery key for you.
I know. So walk me through it, you turn on the machine. Windows boots, you are greeted with a login/password prompt. The user enters their password and now typically have access to everything of value on that machine.
You don't have anything of value on that machine, at least not yet. The user entered their Windows login creds into the fake prompt, but the Windows partition itself is still encrypted.
Now, if this is a Microsoft account whose login creds you've stolen, and if the user doesn't have 2FA set up on their account / you are in a position to manipulate them into allowing the 2FA, then yes you can get into their Microsoft Account and access the data there. And if the recovery key is easily extractable from there as AshamedCaptain said in their comment, then yes you have access to the encrypted disk too. And of course if they reused those creds on other websites you have those too, yada yada.
But still, we are still talking about default configurations, right? You still haven't addressed my point that this evil maid attack already works on any machine where the UEFI isn't password-protected by default.
... or you can just login on the device itself.
(for which I certainly hope doesn't require todays crappy 2FA to work (unless you have something like a yubikey))
Yes, that is still an issue - for now. Which is arguably why these steps are being made. To close that hole one step at a time.
So just to be clear, the hole you're hoping to be closed is not Lenovo's "Allow UEFI CA" checkbox. The hole you're hoping to be closed is a) the ability to change the CAs at all, and b) the ability to disable SB. In other words you're hoping for hardware that can only boot Windows in perpetuity, nothing else.
It's fine if that's what you're hoping for, but I just want you to be aware of that in case you weren't already.
But I do think it is reasonable for a "windows PC" (one where the device is sold with windows preinstalled) only can boot windows by default. As that is what will benefit the absolute vast majority of users (though to be fair, there is plenty of lower hanging fruits than the boot process for most users).
But it is wholly unreasonable for the owner of the PC not to be able to disable that by themselves (without internet access or anything). If the solution to that is to require a UEFI password to be setup (perhaps windows could set the UEFI-password to the same as the main user if it hadn't already been set) - and resetting the uefi-password would wipe any encryption keys in the TPM that is fine (as long as the option to reset the uefi password exist).
And further, not allowing the owner the control to dual-boot windows and any other OS is also wholly unreasonable (but I'm fine with the owner having to enable it in UEFI first).
Can I hope for it? Would put an end to the "slapping Linux on a Windows box and complaining about how it doesn't work right" nonsense. (Probably in the bad way, and almost certainly with massive damage to the wider x86 hardware market, but still....)
One of the things Apple did kinda right was forcing you to buy Apple hardware to run OSX. It would be deeply ironic of Microsoft to cause the same end effect by locking Linux _out_ of all the Windows computers.
That is highly unlikely. The default configuration with a password includes a verification with the TPM. So the process is like this:
power on -> BitLocker asks for password -> password unlocks the TPM -> TPM does its boot verification -> TPM releases the encryption key -> you can boot into win
If you're on a win home installation the password thing isn't even an option, you just get boot verification and have to retrieve the recovery key from your microsoft account if TPM trips (imo somewhat questionable by MS).
Yes an attacker still could. BitLocker is handled within Microsoft binaries in the windows EFI partition. I believe it is specifically bootmgr.efi.
You can still chain load up windows on KVM at this point, however getting the Windows partition decrypted may be difficult and requires faking up a few TPM measurements.
Lenovo locks down hardware. I tried to upgrade the WiFi card in my Yoga 2 and got an "unauthorized hardware" message from the UEFI and it refused to boot until I removed the hardware.
I would not at all be surprised if they're just over reaching.
Lenovo is otherwise known for supporting Linux on their laptops. And yes I know you can jump through hoops and fiddle with scary (for ordinary users) bios options to "fix" this. The point is that you shouldn't have to and this is a bit too convenient for MS to keep competitors off laptops.
Basically, what is needed here is a neutral certificate authority not controlled by a single company with a reasonable process for independent operating systems to get a certificate.
I recently ran into this trying to boot linux on my old imac. Ubuntu actually works but forget about arch, manjaro, and a whole lot of other distributions. Imacs have no off-switch for secure boot that I know off.