Hello, I am using Fedora Workstation Linux and it says in settings that i should activate secure boot. How neccesary is this really? I've heard that secure boot on Linux and on pc in general doesn't really provide that much more security. Is this true? Does it even compare to a locked bootloader on Graphene? And how difficult would it be to activate secure boot on Fedora?
Linux and Secure Boot
Apples and oranges with the secure boot and locked bootloader, however secure boot prevents unsigned kernels from being loaded (which an attacker could place theoretically)
Pair it with LUKS over TPM and it can be a dandy way to prevent someone from infecting your system with physical access
- Edited
Dude this is soo off topic XD
92743 It's not a real implementation of secure boot and doesn't truly work at either hardware, firmware or OS level. It has no actual value. It's there simply to pretend a useful security feature is implemented when it isn't.
raccoondad Nope, it's not a real implementation and has near zero value. The same applies to everything people do with typically very insecure TPMs with traditional desktop Linux. TPM API is also very flawed and difficult to use in a way that truly improves security.
Real secure boot with a real hardware/firmware and OS implementation is very useful. An implementation like this without an actual working chain of verification from a root of trust covering all privileged firmware and not verifying anything beyond one initial part of the core OS is near useless.
- Edited
Secureboot is not really needed on Linux. It can help against some flawed things or against Thunderspy. https://thunderspy.io/
92743
If in doubt you can set it on in the bios. See above.
GrapheneOS What desktop OS do you use?
Linux has support for dm-verity that can be used to provide strong secure boot protection, by verifying every disk read. But for it to work, the partition holding the operating system must be read-only and updated in a similar manner to GrapheneOS where a new signed OS image is downloaded and written. Desktop Linux update model of updating individual packages are not compatible with that. So it is not so likely mainstream desktop Linux will get these features anytime soon. Tails could theoretically switch to use dm-verity, since they already have the right update model and are highly interested in security, but they haven't as far as I know. Also, the security BIOS offers to not be able to circumvent secure boot is sketchy at best.
But I often feel the security benefits of secure boot/verified boot is often overstated. It is only secure until user installed applications start executing. If a user installed application were able to compromise the OS once, they can redo it at every reboot, and most OSes auto-start user installed applications. This has probably also been a contributing factor to the low interest in secure boot on desktop Linux. QubesOS thinks it is far more important to harden dom0 against being able to be compromised at all in the first place. A secure boot/verified boot really only provide the following security benefits:
1) Secure factory default, ie a way to trigger factory default before any user writable/non-verified partition has been mounted. This allow to restore a compromised system to a non-compromised state, without reinstalling the OS from verified external media. But you will either way lose all your data. This is mostly a convenience function to make it easier to restore security post-compromise.
2) Evil maid protection, ie a way to prevent someone with physical access to your device, but without your login credentials, from modifying or compromising the system. For this to work, all user writable/non-verifiable partitions must be encrypted with your login credentials. But it isn't that hard for an evil maid to get hold of your login credentials, with hardware key loggers or carefully placed pinhole cameras, it just raises the bar somewhat.
GrapheneOS Its worse than that. I strongly believe that its purpose was to lock non-MS operating systems out of new hardware under the guise of "security", but that didn't work out as they were forced to let everyone else in anyway. They kept up the charade because dropping it would prove it.
- Edited
I agree with your thoughts on users running code.
But there are many implementations of immutable OSses so this is an already overcome limitation. Fedora rpm-ostree, bootc, VanillaOS, SteamOS, ArkaneLinux and many more or less hacky approaches exist.
Heads is a nice implementation of measured boot, but I dont know about the security of even recent Clevo Laptops TPMs, they are probably pretty bad.
Android phones offer a ton of security benefits that only Macs really have, like soldered storage, a secure element, protected USB ports with a GUI etc. Those come with big downsides, which is why backups on Android suck, for example. Encryption tied to the device has huge problems.
Heads supports that, afaik.
There simply is a ton of money there, so shaming Linux devs makes absolutely no sense. We need big funds and knowledgeable people working on good implementations.
missing-root which is why backups on Android suck,
Backups on android can work fine. Just needs a decent backup utility in the OS. GrapheneOS plans to build one as there is currently a good open source implementation. Ssedvault kind of works but is unreliable.
Also apps have to be designed to properly support OS backups. Or make their own alternative robust backup mechanisms. If they want to provide higher levels of protection via extra encryption they should also think about providing a method to backup that data. That could be via the OS backup system. Possibly with the data there having an extra layer of encryption if the app dev thinks that is necessary.
Recent changes to how app backups work in AOSP, connected to device-2-device migration, are making it possible for OS backup systems to, in most cases, get app data.
ryrona often feel the security benefits of secure boot/verified boot is often overstated.
The main threat android verified boot was designed to guard against is persistent remote exploitation.
GrapheneOS has an improved more complete implementation. Everything thats part of the OS, including updates to system apps like vanadium that happen between OS updates get verified every time anything is read from disk. Also protects against malicious downgrades of some system components unlike stock.
https://grapheneos.org/features#anti-persistence
https://grapheneos.org/releases#2023020200