Vanilla os
It has some sort of verified boot implementation, and security features inspired by Android.
It has no actual verified boot implementation. Which security features in it are supposed to be inspired by Android? These claims don't make any sense. The people working on the OS regularly make false security claims about it and have engaged in attacks on security researchers and actual security projects. It should be avoided.
Certainly the most promising distro from a security point of view.
This is absolute nonsense. Stop pushing this stuff with false marketing here, especially across threads.
- Edited
The last comment in this post are your refering to me or xenibem. I like vanilla os but will have to look more in-depth at your replies as they have spiked my interest to learn more here
xenibem
How is their claim of immutability dubious. Dose AB root Have an implementation problem at its core design?
- Edited
What do you think of Serpent OS and the fact that it is supposed to be the new basis for Solus 5?
UEFI only, wayland only, build from scratch
[deleted]
- Edited
GrapheneOS In my post i also said
Some of the Graphene OS engineers or mobile security experts could easily point out mistakes in the design aspects if they are fundamentally flawed.
Im not pushing anything. Please don't be so hostile against me. I was genuinely interested in the project and wanted to find out if its good or not. Sorry if it came off as if im advertising for them. Im not affiliated with them nor do i have any personal motives to push fake stuff. If it sucks it sucks. Sorry to hear that.
Nor am I affiliated with the Vanilla OS project.
OfflinePuffin How is their claim of immutability dubious. Dose AB root Have an implementation problem at its core design?
In the Pixel/GrapheneOS system, new system images are signature-checked by the bootloader (not the OS). The running OS does not get to decide what goes in the image; only the GrapheneOS signers do.
If via some privilege escalation the system image is tampered with, there will be a dm-verity failure no later than the next reboot.
I am unaware of a desktop OS with those properties.
Very interesting! Thank you
Could an open source bootloader use in this way? Or does there need to be tight integration with hardware.
- Edited
OfflinePuffin Could an open source bootloader use in this way?
This issue isn't whether or not a bootloader is open-source. But if the OS, meaning malware running inside the OS, can tamper with the bootloader, it's not a basis for trust.
OfflinePuffin Or does there need to be tight integration with hardware.
An effective verified-boot infrastructure requires cooperation between hardware and software. In theory this can be done on any kind of machine (phone, desktop), but in practice so far the effective implementations are mostly on phones.
Two recent examples:
- For a while, the bootloader in Fairphone phones used a key for which both halves (public and "private") were public (oops), so in practice anybody could sign any malware-ridden kernel and the Fairphone bootloader would declare it to be genuine (source). This is not a common mistake for phone vendors to make.
- Meanwhile, in the desktop PC world, 200+ devices made that same mistake (source).
My sense is that verified boot works better on good phones (e.g., Pixels, iPhones) than on Apple "desktop" machines, which in turn are way ahead of regular PCs.
Based on a quick glance, it looks to me as if the Vanilla AvB ABroot infrastructure is designed to protect against innocent mishaps during upgrades, not to protect against malware. That doesn't mean it's a bad thing! But if it doesn't protect against malware persistence then it doesn't protect against malware persistence, and then it isn't the same thing as what happens when you boot GrapheneOS on a Pixel, even if the name of the technology is similar.
Oh, also, see LogoFAIL.