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

[binarybanana]

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.

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.

[kpedersen]

We've got some heavyweight security experts checking each tested security attribute, people way clever than you and me. It's certainly not arbitrary.

And yet if you look around, it is all a mess. Until we have completely open-hardware, thinking a "high score" means your machine is secure is just delusional.

If I remove all network cards on my aging Pentium 4, I should in theory have a higher score than most machines, no matter how "modern" they are. Local offline attacks are very limited afterall.

[jntesteves]

Not sure what's wrong, but on my AMD Ryzen 5900HX system, it does give a score.

Good to know someone got it working. I have the same CPU on an Asus laptop (ROG Strix G15 Advantage Edition 2021) and mine says “✘ Supported CPU: Failed”. Admittedly, there's a BIOS update for this laptop I've been putting off on updating for a long time, I guess it's about time I resolve that and check if that helps.

[billyswong]

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.

The most worrying part of TPM to me is, data reliability is actually harmed. If the TPM is done by an removable chip, someone throwing that little chip away may brick the OS partition and make user data lost permanently. If the TPM is done by motherboard/CPU firmware, damage or loss of function to the motherboard/CPU may brick the OS partition again and make user data lost permanently again. Since ransomware is invented, I think we should know better that data loss is the biggest concern in real world security threat. Encrypting a drive in TPM style works for phones only because content in a phone is expected to be synced to the cloud or backed up to a PC. People have prepared that their phones may get lost or be broken at any time. Meanwhile, data in PC are not backed up elsewhere more often than not because of time and/or cost. TPM is introducing extra risk for home users.

[jntesteves]

If I remove all network cards on my aging Pentium 4, I should in theory have a higher score than most machines, no matter how "modern" they are. Local offline attacks are very limited afterall.

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.

Flatpak has its own security indicator at the app level. Would you claim it's incomplete because it says secure when an app runs on an insecure platform? There are many levels to security, it is impossible to conflate the whole thing to a single score. That doesn't diminish the importance of being informed about potential issues at each level. People should be informed of all the relevant issues, they have the autonomy to act on each as they see fit.

I do think the GNOME screen is incomplete, though. If GNOME have a security center, this is a good start, but in the future I hope it also includes the other potential threats I mentioned. Specially SELinux status, even Android informs that.

[erniv2]

I believe you misunderstood me. I complained not about lack of possible actions from the GUI, but the utter lack of documentation and explaination. I do not expect most of these to have a simple "fix this" button. But I do expect:

• Explanations for what they mean/do
• Information about if the user can do anything about them, and if so what (look for things in BIOS, change kernel command line, ...)
• If applicable: Any risks associated with doing those actions (e.g. "oh by if you set the option, on some broken systems your system might not boot due to broken ACPI/UEFI/whatever. This has been observed on some vendor X and vendor Y systems so far.")
• Links to more information.

Since this is linux just write a manpage like.

IOMMU: If your CPU supports this feature it provides an insulation layer between Hardware and software DMA for RAM access.

DMARp: This feature prevents DMA access at boot time everything goes trough the IOMMU it´s there to prevent drive by hijaking if there was physical acess to your Hardware.

DMAR: This feature prevents DMA access at runtime everything goes trough the IOMMU to prevent injection of malicious code.

TPM2: If your CPU supports this feature you can use advanced features like disk encryption, if you have a working TPM2 and use a type of encryption that requires it (windows bitlocker) do not deactivate this feature your system will become unbootable.

Secure Boot: This feature provides you with a set of keys saved in your UEFI with certified Bootloaders, please note this feature usually only works with Windows or with certified Linux Distributions (Fedora/SUSE/RHEL/Ubuntu), if you use this feature and have a uncertified bootloader your system will become unbootable.

Now someone just has to cut&paste this to some manpage and submit it to the gnome guys .

[hughsie]

Now someone just has to cut&paste this to some manpage and submit it to the gnome guys .

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. For example, see this:

Screenshot from 2022-08-24 12-08-47.png

[stormcrow]

“Our distro isn’t secure. Instead of fixing it, let’s hide the panel so people don’t find out!”

- Ubuntu devs

Apparently you and the people liking your comment either didn't read the article at all or lack reading comprehension. The feature is effectively nonfunctional which is why it was removed.

If you bothered RTFA, it's only partly functional, has no way to fix any of the problems identified, and has no context awareness that some of those "security features" are entirely CPU model dependent or not necessarily part of any given threat identification process. So it's useless, tells people things they may or may not be able to remedy, and the app can't even fix what it's complaining about. It's entirely correct to remove such a useless app till it's actually useful. This is where Gnome's traditional lack of care for the user experience - not just the core team's experience but everyone's - is biting them in the ass. Again.

[hughsie]

Local offline attacks are very limited afterall.

Most real-life UEFI attacks are done offline. Why do you think people put special nail-polish into the security screws when going through airport security? e.g. https://lifehacker.com/use-glitter-n...roo-1493599646

[kpedersen]

Most real-life UEFI attacks are done offline. Why do you think people put special nail-polish into the security screws when going through airport security?

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.