Originally posted by ssokolow
View Post
Announcement
Collapse
No announcement yet.
Ubuntu Isn't Yet Onboard With GNOME's "Device Security" Screen
Collapse
X
-
- Likes 6
-
Originally posted by hughsie View PostWe've got some heavyweight security experts checking each tested security attribute, people way clever than you and me. It's certainly not arbitrary.
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.
- Likes 4
Comment
-
Originally posted by Vistaus View PostNot sure what's wrong, but on my AMD Ryzen 5900HX system, it does give a score.
Comment
-
Originally posted by binarybanana View Post
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.
- Likes 6
Comment
-
Originally posted by kpedersen View PostIf 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.
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.
- Likes 5
Comment
-
Originally posted by Vorpal View Post
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.
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 .
- Likes 2
Comment
-
Originally posted by erniv2 View PostNow someone just has to cut&paste this to some manpage and submit it to the gnome guys .
Screenshot from 2022-08-24 12-08-47.png
- Likes 4
Comment
-
Originally posted by cooperate View Post“Our distro isn’t secure. Instead of fixing it, let’s hide the panel so people don’t find out!”
- Ubuntu devs
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.
- Likes 7
Comment
-
Originally posted by kpedersen View PostLocal offline attacks are very limited afterall.
- Likes 4
Comment
-
Originally posted by hughsie View Post
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?
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.Last edited by kpedersen; 28 August 2022, 04:25 PM.
- Likes 3
Comment
Comment