There is such a firmware setting, hence "by default". That doesn't make it acceptable - the default security settings on a general purpose PC should not prevent booting alternative operating systems that don't compromise the security model.
It doesn't seem much different from the F12 menu that lets you select an alternate boot device.
How exactly does this mean they "prevent booting alternative operating systems"?
At this rate it prevents someone from booting in a 'malicious' OS quickly.
Though I'm not sure if it's worth it, especially not if changing the bios is just a matter of seconds anyway (ordinary users probably won't put a password on it).
This is defense-in-depth level stuff.
System doesn't boot because PCR 7 is now different, just like it would be if you didn't have to do those additional (rapid) keypresses. This is not the threat model you're looking for.
That fob could then compromise the system when the computer was rebooted. The Lenovo bios setting being discussed would prevent that.
BTW Can you clarify if you think the feature from Lenovo is a good or a bad thing given your claim that it's very easy to disable?
If so, they need not come close to your laptop at all, certainly not close enough to change BIOS settings.
Wouldn't even call it "in depth", disallowing an alternative boot should be one of the first things any decent IT staff should do on any company machines, and therefore so should direct-to-consumer pre-installed tech like this.
99% of computer users are just consumers, nobody should have to think about security when they first get a new system beyond setting a password.
They do not sign everything nilly-willy; they refused to sign grub, that's why linux distros use shim.efi.
One could argue that distrusting platforms signed with MS's 3rd party certificate offers marginal additional security but that doesn't contradict the original point made about defence in depth.
But it certainly does damage the competition.
You're further limiting the number of images that can boot. This is a point you've made yourself so I don't really see how you need a further demonstration.
What you can argue is whether that marginal additional security is negligible enough be pragmatically worthless. And I'd probably agree with you there. However that doesn't dismiss the point that it does add a marginal additional security from the perspective of "defence in depth"[1]
[1] https://en.wikipedia.org/wiki/Defense_in_depth_(computing)
> But it certainly does damage the competition.
I'm not convinced it does in any meaningful way. Maybe (again) marginally it might but it's trivial to disable and most Linux users are probably used to jumping into the uEFI to enable booting from install medias anyway (I know I am).
I'd argue your statement here requires a greater burden of proof than the one you're arguing against.
That does not mean it improves security. If the images it allows to boot are less secure than those it prevents, it lessens security.
> I'm not convinced it does in any meaningful way.
It does booting Linux harder exactly to these users that it claims to protect.
So yes, it "protects" them from trying competing product.
> disable and most Linux users are probably used to jumping into the uEFI to enable booting from install medias anyway (I know I am).
Power users can do it; less experienced users consider that difficult, especially if they are not familiar with the concept. This all contributes to the image that Linux is difficult to install and use. Linux forums are full of discussions on this topic.
While it is just an artificial hindrance.
Would be it OK for Windows users to fiddle with UEFI settings before they can use Windows? If not, why is it OK for Linux users? Windows gets a clear advantage here.
I appreciate what you're saying but your logic doesn't really work:
- The only image allowed is Windows. Anything else is disallowed. Those images might be malicious (eg someone somehow stole MS 3rd party cert) or they might not. But not allowing them is more secure than allowing them because you're reducing your risk.
- Furthermore, saying some images allowed are less secure (ie Windows) than the ones that aren't (eg CentOS) doesn't mean this "feature" (if you can call it that) doesn't still add some additional security. Because (and at risk of repeating the above), this still blocks some additional images that might be a security risk. Hence it reducing your risk and hence it providing additional security from the perspective of defence in depth.
- The point of "defence in depth" is not to have a single security countermeasure that acts as a silver bullet against attacks. It's to provide a layered approach where cumulatively they protect you. This "feature" certainly fits that criteria.
This is why I said the question shouldn't be "does it provide additional security?" but rather "is that additional security significant enough to warrant the other impacts (such as those you've outlined?"
If you were to make that point instead, then I might agree with you. But to say it doesn't provide any additional security really misses the point of how security is evaluated.
> > I'm not convinced it does in any meaningful way.
> It does booting Linux harder exactly to these users that it claims to protect.
That's not a counterargument, it's a contradiction. I don't really see the point of a "oh yes it does" / "oh no it doesn't" pantomime style argument. If you are able to cite how the short activity of unchecking an additional UEFI option is significant enough to turn people off from the already complicated process of installing Linux then I'd be interested to see it. Otherwise we might just have to agree to disagree.
> Power users can do it; less experienced users consider that difficult, especially if they are not familiar with the concept. This all contributes to the image that Linux is difficult to install and use. Linux forums are full of discussions on this topic.
But how many of those people are buying ThinkPads to install Linux who are not power users? I'd wager if you were to draw a Venn diagram, those groups would barely, if at all, intersect. And more often than not, you have to alter UEFA parameters to boot from removable devices regardless of your setting in secure boot.
> Would be it OK for Windows users to fiddle with UEFI settings before they can use Windows? If not, why is it OK for Linux users? Windows gets a clear advantage here.
This I do 100% agree with. I never liked secure boot to begin with because of exactly this reason. Still dislike it now and certainly don't agree with what Lenovo are doing with regards to the original topic. But that is an entirely separate point to the one made previously about defence in depth.
Here I think lies the issue of our discussion. You're arguing against a technical point with an emotional claim of morality. While I completely agree with your point about morality, it's doesn't address the technical point you're trying to argue against.
> - Furthermore, saying some images allowed are less secure (ie Windows) than the ones that aren't (eg CentOS) doesn't mean this "feature" (if you can call it that) doesn't still add some additional security. Because (and at risk of repeating the above), this still blocks some additional images that might be a security risk. Hence it reducing your risk and hence it providing additional security from the perspective of defence in depth.
However, that is not increase in security. It is to increase the lockdown. And increasing lockdown is a poor proxy for quantification of security of specific images. It is easier, with that I can agree.
By the same token, locking out Windows images and allowing CentOS images also increases the security, but then the argument would not be about security anymore, but change to convenience of majority.
> If you are able to cite how the short activity of unchecking an additional UEFI option is significant enough to turn people off from the already complicated process of installing Linux then I'd be interested to see it. Otherwise we might just have to agree to disagree.
You had exactly that in the TFA. It invalidates PCR7, thus invalidating the TPM secrets. If the user uses Bitlocker and didn't save the recovery key, he just lost all his existing data by flipping that option.
It is another significant hoop the users have to jump; and it just happens to more complicate Linux usage. Those incompetent Linuxers, cannot make anything user-friendly...
> But how many of those people are buying ThinkPads to install Linux who are not power users?
Many normal users are not thinking about Linux when they purchase their gear; they will want to try it later, once they used the hardware for a while. If this wasn't a case and users would do research ahead of purchase, the majority of hardware problems under Linux would not exist.
> You're arguing against a technical point with an emotional claim of morality. While I completely agree with your point about morality, it's doesn't address the technical point you're trying to argue against.
My point is that it is not a technical issue. It is political issue masquerading as technical one. So a party A designs a system that favors products of party A and it just happens to thow a curveball at everyone else. Color me surprised. Real technical problem would not favor a specific party.
In this instance it is both
> And increasing lockdown is a poor proxy for quantification of security of specific images.
You do realize that locking stuff down is one of the core tenants for securing systems?
> By the same token, locking out Windows images and allowing CentOS images also increases the security
If your system is shipped to run Linux then yes, locking out Windows images would increase the security.
> but then the argument would not be about security anymore, but change to convenience of majority.
You're flip flopping all over the place with different topics. If you want to talk about convenience then I agree that locking systems down affects user convenience. It's a well known adage that security is usually a trade off between convenience and protection. But you weren't talking about convenience, you were talking about security. Which is why I've been talking strictly about security.
With the greatest of respect, you're coming off a lot like you don't really know this subject matter considering how poorly you're sticking to topic and how you're misunderstanding even many of the basic principles of security.
> It is another significant hoop the users have to jump; and it just happens to more complicate Linux usage.
I agree it's another hoop but you haven't yet demonstrated how it's significant despite me asking you to substantiate that claim a few times already. It feels to me like you're just throwing in adjectives for dramatic / emotional effect rather than having a rational conversation here.
> Those incompetent Linuxers, cannot make anything user-friendly...
Why should you care what other people think about Linuxers. Just use the platform you want to use instead of seeing this as some kind of holy war where you need to convert Windows users into Linux users.
> Many normal users are not thinking about Linux when they purchase their gear; they will want to try it later, once they used the hardware for a while. If this wasn't a case and users would do research ahead of purchase, the majority of hardware problems under Linux would not exist.
I've been using Linux since the 90s (and as my primary OS since XP was released and BeOS deprecated). I've never once shopped around for Linux compatible hardware and never once ended up with a machine that couldn't run Linux because of it. Peoples complaints about Linux compatibility are, in my experience, largely over told.
> My point is that it is not a technical issue. It is political issue masquerading as technical one. So a party A designs a system that favors products of party A and it just happens to thow a curveball at everyone else. Color me surprised. Real technical problem would not favor a specific party.
I think you're talking this far too personally. The simple solution here is you can just buy someone else's equipment instead. Getting angry on a forum isn't going to change anything (tbh neither is boycotting Lenovo but at lead doing that can give you some level of control).
Of course this is a mechanism to further advertise locking down general computing and nothing else. It is not new and security is a bad excuse.
That's incorrect. There is malware out there that can only work if you don't have Secure Boot enabled. The setting OP didn't disable, Device Guard, prevents the abuse of 3rd party signed bootloaders, another attack vector basically.
This is a step up for most people that ever stay on Windows and doesn't affect the slightest someone who wants to install Linux, they still have to boot from an external device or wish to change a few UEFI settings.
> Of course this is a mechanism to further advertise locking down general computing and nothing else. It is not new and security is a bad excuse.
Framing Secure Boot as some kind of Secure Boogeyman is not conducive, brings the discussion into tinfoil scenarios without any potential practical outcome (nobody is going to remove SB or DG).
As long as Linux vendors or people can get or enroll their own keys and disable any potential presets, it's a step up in security for everyone.
No, very few models sold auto-encrypt because most have *the very least* one untrusted DMA-capable bus. They might even have Device Guard enabled, but that's often insufficient. Not to mention other reasons why devices might be considered noncompliant, like lack of HSTI (though that's more common with desktop motherboards, of which some might even have all other features Device Guard consists of).
At this point in time, I'd consider auto-encryption rare. Maybe in five years and a few refresh cycles.
> A drive-by malware infection will be blocked by that. The ones who aren't in that scenario probably aren't using hardware that has this configuration, so it does nothing to protect them.
No, because previous point.
> who are targets of adversaries performing bootkit attacks, and who don't have a Bitlocker configuration that's sealed to PCR 7, I'd actually be willing to bet that you're going to find 0 of them.
Me finding someone getting actually targeted? Indeed unlikely.
Me finding someone with some especially nasty variant of Emotet? Not at all unlikely.
Device Guard enabled devices certainly make life harder for attackers, even if BitLocker is not (auto-)enabled.
That's your mistake here, you saw it in a large enterprise, the context is "average user".
> 3rd Party UEFI CA disabled by default who isn't disabling untrusted DMA-capable buses is selling snakeoil, and the ones who do aren't obtaining meaningful additional security by doing so.
Some of the buses that haven't been whitelisted are only internal, so technically not snakeoil, just won't let you auto-enable encryption.
This is a malicious thing to say considering the context (the same problem would affect MS OSes too), and for all practically purposes: since Windows 8 _all laptops_ that I have been able to buy had Bitlocker enabled out of the box (to my annoyance), not to mention that it was practically standard IT police for any large Windows shop.
Please, the current context is "average user" not an "average enterprise". In the latter case I agree with your assessment.
Microsoft doesn't signs arbitrary bootloaders, normally just the shim from RH that needs to have a list of earlier signed 2nd stage bootloader (versions) with now known security issues and reject them.
Debian, Fedora, ... use already trusted and signed bootchains, but they are excluded by choice without any benefit of security whatsoever.
IMO this smell again like classic Microsoft EEE...
So, we're literally at the point where we have to disable parts of chip (the Device Guard / Secure Core / Pluton) in order to boot _any_ non-MS OS scenario, and you are still claiming that this is scaremongering ?
At which point it stops being a "tinfoil" discussion ?
> As long as Linux vendors or people can get or enroll their own keys and disable any potential presets, it's a step up in security for everyone.
Microsoft _already_ promised that there would be a way so that non-MS OS manufacturers would be able to sign their software so that it would NOT REQUIRE fiddling with the system firmware in order to boot them, even with Secure Boot enabled. This is what the UEFI CA was for. You just insert a SUSE USB pendrive, use the firmware boot manager (or even Windows own' "boot from USB device" option in the Settings panel!) and that's it.
Your system is no more compromised by this CA than by allowing MS OSes in the first place. This CA is MS, too. They vet everything they sign. They blacklist stuff that could have been used to compromise devices. They have forced GRUB among many other distributions to align to their whims in order to be signed.
Removing this key and relenting on this promise (which actually they have already done several times) means that there is NO WAY for a non-MS operating system to transparently boot on Secure Boot hardware. You have to fiddle with the system firmware, battle with a lot of Scary Boot Prompts that will drive many users away (even advanced ones!), and with the easiest option likely being to disable Secure Boot altogether which per your own words will reduce the security level of users.
Not to mention of the unfair advantage MS has since their OSes will still boot transparently on these hardware, no matter what the firmware settings, no matter if the device came with no OS or even a Linux distro to begin with.
I have already claimed that MS revoking a distro's signatures is basically a death sentence for that distro. Here we have an article about a manufacturer revoking _all_ distro's signatures, and you claim that "this is not a conductive discussion" ? Give me a break.
Yes, because the same way you have to enable booting from an USB stick.
> At which point it stops being a "tinfoil" discussion ?
See my last sentence in my previous comment.
> Not to mention of the unfair advantage MS has since their OSes will still boot transparently on these hardware, no matter what the firmware settings,
Making a fresh install of Windows is equal in complexity, but it is preinstalled more often certainly.
> Removing this key and relenting on this promise (which actually they have already done several times) means that there is NO WAY for a non-MS operating system to transparently boot on Secure Boot hardware.
That's not a case with Secure Boot alone, it's a case with Device Guard. Device Guard you can disable. It's a toggle like all the rest, no promises broken.
> I have already claimed that MS revoking a distro's signatures is basically a death sentence for that distro. Here we have an article about a manufacturer revoking _all_ distro's signatures, and you claim that "this is not a conductive discussion" ?
Yes, because what you've said is not correct.
NO. It's not the same way. On most if not all devices I can boot from a USB stick literally from the Windows settings panel itself (search for Advanced Startup)! No need to even see how the system firmware looks like. Even on hardware as "locked down" as x86 MS tablets, I can hold Volume Down key during boot to boot from a USB stick. Again, enabled by default , and no need to even look at the system firmware !
From that point on, _if the UEFI CA signature is installed_, the distro's setup experience takes over, which is already under the control of the distro itself.
> Making a fresh install of Windows is equal in complexity, but it is preinstalled more often certainly.
"Equal in complexity" to what ? Most distros and even Windows install can be done with your eyes closed and hitting the enter key repeatedly, specially if you are just overwriting whatever was on the computer before. Installing OSes are typically designed to be as easy as possible. We've had decades of improvements here, both for Windows and non-Windows.
Changing settings and disabling secure boot on the system firmware is NOT designed to be as easy as possible. In fact, many times it is explicitly designed to be as scary as possible, precisely for security reasons! (with the intentional addition of Scary Boot Prompts). But worst of it, this part of the experience is NOT controlled by the OS vendor ! That by itself is already suficient to have a completely unfair situation. No matter how much effort you spend on making your OS install flow as smooth as possible, your user still has to fight the system firmware... but only if you're a non-MS OS!
> That's not a case with Secure Boot alone, it's a case with Device Guard. Device Guard you can disable. It's a toggle like all the rest, no promises broken.
The promise is that there would not need to be a toggle to switch. That's what's been broken!
> Yes, because what you've said is not correct.
And it is not correct because ..... ?
If you're just saying "it's not easy enough", well, that's a matter of opinion.
You do not even need to imagine "what I am proposing" because I am not proposing anything whatsoever: the MS UEFI CA signs non-MS operating systems.
MS just needs to not relent on its promises.
Do you really run a Linux that comes from a "vendor"?
Sucks to be you.
Giving the user more hops to jump through, when they want to try alternate (signed!) operating systems? Like, you have nice encrypted disk here, are you willing to lose it, when you flip the setting?
it's a very dangerous attack vector.
EDIT: writing from a Lenovo laptop where Linux it's the sole OS installed.
Allowing Linux to boot was a hundred times simpler than allowing DOOM to run on my 486 with 4MB of RAM.
And you need that for recovery purposes, at least.
The signature could come from a stolen certificate or a malevolent actor (are we sure the famous three letter agency has no way of signing binaries?).
Not trusting external and/or removable storage as a valid bootable source is a sensible default.
p.s. writing from a Lenovo laptop where Linux it's the sole OS installed.
The default for years was to boot from external storage, when the internal is not bootable. To change it, you would have to change boot priorities or manually use the built-in boot selector.
Not on my computers for the past 20 years.
If the default is not bootable a “no bootable device found” message appears.
computers should never automatically boot from external storage, unless the user wants to.
- try to boot the internal devices
- then try external (some even distinguish optical and key fobs)
- then try PXE
and only when all of these fail, message the user "no bootable device found".
And even then this message appeared
Press any key to boot from CD...
because computers should never automatically boot from external or removable storage
that's why a more modern version of the same message exists
It won't boot from USB if the internal drive boots, or unless I manually change boot order.
Having said all that, this comment is all anecdotal, much like yours.
The ubuntu usb key you are booting is safer than what you already got installed...
Lenovo does that for you
They are legally responsible.
> The ubuntu usb key you are booting is safer than what you already got installed...
Have you read my post?
I use Linux, I'm writing from Debian, on a Lenovo laptop.
It took 10 seconds to allow Linux to boot.
On this specific Z13? Or other model, which wasn't "improved" yet?
10 seconds at most.
no need for being sarcastic.
I do want to use secure boot and TPM2 (I do, currently). Just not with windows. Why should be secure boot windows exclusive feature? Until now, it wasn't.
There was no sarcasm.
it's a solution
it's only a matter of choice, there's no wrong choice, choices are personal.
You're complaining about something that's very easy to overcome.
> I do want to use secure boot and TPM2 (I do, currently). Just not with windows
You can.
just disable device guard.
> Why should be secure boot windows exclusive feature?
you are angry about the wrong thing
device guard and secure boot are different things, related, but different.
> device guard and secure boot are different things, related, but different.
The problem is that it can have potentially catastrophic impact. If the user enabled Bitlocker, and didn't save recovery key (it will happen for mainstream users), he can lose his windows drive when he tries linux.
As I wrote above, another extra-hop for those who would like to go off the beaten windows path.
it's a configuration option.
it's a bad workaround for you.
I disagree.
> If the user enabled Bitlocker, and didn't save recovery key
then the user is responsible of being incautious.
case closed.
Congratulation, you just invalidated the entire raison d'etre of both Secure Boot and this new Device Guard.
Still not perfect, but way better than without.
But worst of all: Superfish was actually _signed_ itself. MS has improved the level of vetting they do now, specially for kernel drivers, but how come anyone can still claim with a serious face that a signature requirement from one CA specifically improves security against malware _from that CA_ (or their associates) ?
I didn't say it was, you kinda ignored the context. The person who I replied to was asking how can they trust their Windows is genuine, I replied to them that the feature causing a stir here does protect against some types of malware.
It's a fair assumption that the next thing akin to Superfish would try to implant itself deeper, if given the chance, Device Guard does eliminate some of those ways.
> for preinstalled software such as drivers
If that driver is actually malicious then Early-Launch Antimalware alongside the kernel being protected, can get rid of it.
> There would be absolutely no difference on whether you used Secure Boot or not.
I wasn't talking exclusively about Secure Boot.
> But worst of all: Superfish was actually _signed_ itself.
Sure, now there's a toggle that won't trust some signatures that aren't as heavily vetted (amongst many other things). How is that "ridiculous" or "won't make a difference". Are you just looking for a reason to argue?
> [Device Guard] does prevent quite a few different malware preinstallation methods. Including the infamous Lenovo one.
Which is the infamous Lenovo malware "preinstallation method" ?
How would a signature system would have prevented malware that was literally signed by Lenovo _and_ MS from being preinstalled on a Lenovo OEM image shipped with Lenovo hardware ?
Yes, and I didn't call it a "kernel rootkit" as you said I did.
> How would a signature system would have prevented a malware that was literally signed by Lenovo _and_ MS from being preinstalled on a Lenovo OEM image ?
Because AFAIK Device Guard sets limitations to what WPBT can do. Not to mention it's likely that additional kernel and boot integrity helps against all types of malware.
If people in corporate environments want to disable this, they can set a BIOS password to keep others out of the boot menu.
So the security benefit would be avoiding 3rd party and signed, but potentially vulnerable "bootloaders"
(Context: I wrote a significant portion of the infrastructure used to support Linux booting on systems with UEFI Secure Boot)
[1] Modern TPMs have 24 PCRs that can be used to measure different parts of the boot process, but the general expectation is that only 0-7 will be used by the firmware. On UEFI systems, PCR 7 contains information about what the platform's secure boot policy is, and which keys were used to verify the boot process. Booting something signed with a different key will result in PCR 7 having a different value, which is something that can be detected by tying encryption keys to specific PCR values.
> [...] the firmware defaults to not trusting bootloaders or drivers signed with the Microsoft 3rd Party UEFI CA key.
The whole point of secure boot was that there is a known set of "good actors" who are trusted by default, so that you can boot 1. Windows 2. common Linux distros - without any fuss, and 3. Any other system - with a few extra steps to prove you know what you're doing.
They've de-ranked the set #2 and threw it in the bag with #3, which doesn't really do much at all to improve security, but it does inconvenience and disincentivise the users from using a Linux distro on this hardware.
It's most likely an honest mistake, a sign of incompetence, or a dick move. Write them an angry letter and carry on.
Well no, it's not Lenovo really, it's Microsoft and its Device Guard / Secured Core that has done so. You can disable that just as easily as you can boot from an USB stick.
Key quote here; a good practice is to never trust e.g. USB sticks.
What's the news here?