System integrity and FOSS politics

Posted Jun 21, 2024 17:08 UTC (Fri) by NYKevin (subscriber, #129325)
In reply to: Problems with capabilities by malmedal
Parent article: A capability set for user namespaces

> It is a bit sad that nobody seems to have done this for Linux.

Any technology that maintains system integrity is automatically seen as suspect, because maybe someday someone will use it to lock users out of their own systems. It's really quite unfortunate, especially seeing as the average user has no desire whatsoever to administer their system in the first place (why do you think people keep buying Apple/Google/etc. products?). But I don't see a good compromise. For the sake of simplicity, let's acknowledge that GPL3 exists and provides a legal solution,* but from the technical side, this is a set of conflicting requirements:

* We want to let the sysadmin change the system in whatever way they like.
* We want to empower the sysadmin to prevent unwanted changes to the system.
* We do not want to make evil maid attacks any easier than they already are, and ideally it would be nice to make them harder (but that is very difficult).
* We do not want the sysadmin to sell the device to someone else without handing over root.

The obvious problem is that the system has no way of knowing which instances of physical access are legitimate and which are attacks, so it cannot differentiate between a sale and an attack. So every time integrity comes up, large numbers of developers and commentators simply assume it will be used in this manner by hardware manufacturers (in fairness, they're not wrong), and controversy ensues.

Disclaimer: I work for Google, they do integrity stuff on some of their devices, they also lock down some of their devices, opinions my own, etc.

* It's a "solution" assuming your counterparties all comply with copyright law. You can talk to the various GPL enforcement people to see how well that works in practice. There is also the small problem that some developers do not like GPL3 very much, and refuse to use it, see for example Linus's stance: https://www.youtube.com/watch?v=PaKIZ7gJlRU

System integrity and FOSS politics

Posted Jun 21, 2024 18:46 UTC (Fri) by somlo (subscriber, #92421) [Link] (3 responses)

> * We do not want the sysadmin to sell the device to someone else without handing over root.

I think this is the crux of the issue. In an ideal world, the legal new owner of a device should be able to force a "factory reset" (erasing existing data to protect the previous owner's privacy) without having to rely on the cooperation of either the previous owner or of the manufacturer.

Not sure that's a problem solvable by technical means, though it would be nice if it were... :)

System integrity and FOSS politics

Posted Jun 21, 2024 19:34 UTC (Fri) by atnot (subscriber, #124910) [Link] (2 responses)

Yes, there is one way to tell the difference between a thief and someone trying to sell you a device, and it's that the latter generally tends to follow local laws and regulations.

Unfortunately it's somewhat of an uphill battle because that mostly breaks the game console business model and few lawmakers are going to want to touch that. But it should absolutely be the case for every general purpose device, at absolute minimum once it's official support ends.

System integrity and FOSS politics

Posted Jun 22, 2024 22:25 UTC (Sat) by smcv (subscriber, #53363) [Link] (1 responses)

I think the way Google's Nexus/Pixel Android devices do this is probably one of the least-bad compromises available here. With physical access, you can trigger a factory reset from the bootloader, or turn off secureboot-style authentication so that you can substitute your own OS or recovery image; but the early-boot firmware will only allow either of those things after erasing user data, so you can't use them in an "evil maid" attack (the worst you can do is denial of service, you can't compromise confidentiality).

System integrity and FOSS politics

Posted Jun 23, 2024 10:15 UTC (Sun) by excors (subscriber, #95769) [Link]

I think there are some other important features of Android's system: the original user will definitely notice if you wipe the user data on their phone. They might not understand exactly why that happened, but hopefully it'll make them suspicious enough that they'll notice the boot message saying "The bootloader is unlocked and software integrity cannot be guaranteed. Any data stored on the device may be available to attackers. Do not store any sensitive data on the device". And some apps, especially banking apps, will refuse to install on an unlocked device.

That means the system doesn't just protect confidentiality of the existing user data; an attacker can't easily compromise future confidentiality either, by installing a backdoored OS image and handing it back to the original user (or selling it second-hand to a new user) and having them continue to put confidential information into it.

Unlocking the bootloader doesn't allow you to replace the bootloader itself with an unsigned version, so you can't hide that boot message. So you can't have fully GPLv3 firmware, because the bootloader remains locked down by the manufacturer, but at least most of the firmware is user-replaceable.

This isn't a particularly general solution though - it works but phones but not for e.g. IoT devices that might process sensitive data (like anything with a camera in your home) but don't actually store user data (so users won't care if it gets wiped) and don't have a frequently-viewed screen (so they can't easily present warnings to users).

System integrity and FOSS politics

Posted Jun 21, 2024 19:20 UTC (Fri) by malmedal (subscriber, #56172) [Link]

This is orthogonal to secure boot.

Even on Macs SIP can be disabled, and you can also replace the kernel with a self-compiled one if you want. All you need is physical access. (and the firmware password if there is one)

My guess is that SELinux stole the niche and crowded out this approach.