So … device attestation … the same shit coming from Google, Microslop and others. At least Poettering is consistent with his shit ideation.
People are wild. Its just like locks on doors. Yes very useful, the user should have the keys, yeah corperate ownership of keys is nightmare.
So, basically, they want to do to Linux what google is doing to android and tried to do to web. No, thanks.
That’s not at all what this about. Poettering has given quite a few talks about this subject, that being Linux boot chain verification and integrity.
One of the core concepts is measured boot. The TPM on your CPU measures the values of various pieces of software in the boot chain. If a measurement does not match, then the system will not boot because it could be compromised.
And unlike secure boot, this is a decentralized system. It’s not some corporation like Microsoft saying “this software is signed with this approved key, so it may boot”. It’s your own system checking the software and recording the expected value so that when you boot up, it checks again to make sure they match.
It’s not about apps asking doing things like DRM checks or anything like that. In fact, it can’t. GrapheneOS implements a system just like this to ensure the OS has not been tampered with.
The problem is that this value can be compared to a list of “allowed” values. Therefore it opens the gate to creating software that would require only certain “whitelisted” systems to run it. Such list can be easily updated automatically once those “whitelisted” systems update. Therefore an argument “updates would break it” do not actually work.
This is precisely how play integrity works on android. And Poettering intensions do not matter much. His system can be used like that and therefore it will be used like that.
The problem I see with that is that these values are far from regular. At the very least, the TPM will be checking the Linux kernel, bootloader, BIOS firmware. Any update to those will result in different measurements. And it’s not just the version that matters, but also the configuration. And there’s more things the TPM can measure, like connected hardware devices.
To reiterate, it’s not the case that the distro provides a hash of what the measurement should be. When you install, the actual software gets installed gets measured and recorded. That first measurement is automatically trusted, assumed to be good. It’s unique to your machine. Your machine will only boot so long as those measurements match. Those measurements only get updated when measurements are re-run, which is done after system upgrades.
Creating an allow list that works for most people would be next to impossible. The Secure Boot approach is much more suited for this task. I can only see this TPM allow-list approach working on corporate machines with controlled hardware and software updates. But at that point, using a custom secureboot key is easier and less liable to break.
In what sense?
They want to create a mechanism for software to determine on which system it allows a user to run itself. Google “play integrity” on android and google’s proposal for web integrity API.
Good luck. Take away the main reason people move off Windows to begin with and see how well that goes, especially for alt-init distros.
Well, we have a systemd creator and Microsoft employees here…
They haven’t announced anything other than a vague outline of what they’re trying to solve, it could be implemented in so many ways at this point.
It’s not vague at all if you know Poettering and have watched his talks.
This is about securing the boot chain to ensure the integrity of the OS. Ie, someone hasn’t replaced your GRUB with one that looks exactly the same but secretly records your disk password.
It does so in a decentralized way, so anything like Play Integrity would not make sense in the slightest. It’s the TPM chip measuring values and ensuring they match previous recorded values (and the values to change, such as after updates, so after updates are run, the expected values are updated). It’s not a Secureboot-like system that would make it more feasible to have a Play Integrity-like system.
The problem with entire concept is the assertion that “after updates are run, the expected values are updated”. If the administrator can cause the expected values to be updated, you must assume that an attacker who can replace GRUB, in your example, can too, rendering the whole thing ineffective. If the administrator can not cause the expected values to be updated, we’re into an Android like situation, where the vendor decides what you’re allowed to run on your machine. Neither outcome is better than what we have now.
Lennart Pottering has an unfortunate habbit of deciding to fix problems that don’t actually need fixing, then coming up with a vastly overcomplicated solution, takes years to implement, and doesn’t actually provide much or any benefit over what existed before. Any benefit that does occur tends to be the sort of thing that could easily have been added to the previous system, but noone had because it wasn’t actually a pressing concern. One need only look at his history with PulseAudio and systemd to see examples of this. He also tends to be quite rude and dismissive to anyone questioning him, or pointing out architectural issues.
The problem with entire concept is the assertion that “after updates are run, the expected values are updated”. If the administrator can cause the expected values to be updated, you must assume that an attacker who can replace GRUB, in your example, can too, rendering the whole thing ineffective
This TPM stuff is focused on verifying the integrity of the the boot chain. It’s meant to protect against things like replacing GRUB or changing GRUB options in a malicious way. If that stuff is detected, the system won’t boot.
It’s goal is not to prevent malicious changes in userspace, after the system is booted. Protections against malicious userspace modifications must come elsewhere, like SELinux, AppArmor, sandboxed apps, Wayland, etc.
If the administrator can not cause the expected values to be updated, we’re into an Android like situation, where the vendor decides what you’re allowed to run on your machine. Neither outcome is better than what we have now
What do you mean by vendor here? Initially we were discussing applications doing some sort of system integrity check to decide whether or not the application would run. But now it seems like you are referring to the distro deciding whether or not you are allowed to do things.
But again, these checks are just for the OS and it would not make sense to try and turn this into a DRM-like system when Secure Boot is much better suited for that task.
And distros already control what you can and cannot do by how they choose to build the OS. Lets consider Aeon and Universal Blue.
Aeon is an OS that implements things that Poettering is discussing. Uses TPM to verify the integrity and unlock the disk if everything is fine. It also is immutable, which limits user customization in some ways as part of its philosophy. It discourage OS modifications and encourages use of Flathub and distrobox.
The Universal Blue family of distros does not implement Poettering’s stuff (though there is an option to do so). But it has similar restrictions as Aeon, discourages OS modifications, encourages use of Flathub/Homebrew/Distrobox.
My point is that verifying the boot chain integrity largely does not matter when it comes to user choice. While the two I mention do have restrictions, they are only philosophical, you could build a system that has these boot chain integrity checks and it not immutable. Measured Boot is great for this task because it puts the user is control, you don’t need to worry about the software being signed with some third party’s key to boot.
Lennart Pottering has an unfortunate habbit of deciding to fix problems that don’t actually need fixing, then coming up with a vastly overcomplicated solution
I agree in some respects. I like immutable distros, flatpaks, and sandboxed/containerized stuff, but sometimes you just need to install software on the host, unsandboxed. The big thing is that immutable distros want the OS and software on top to be cleanly separated.
Some say to use Hombrew, which will take up quite a bit of space and will not always work (like SELinux permission issues) and I don’t necessarily like it how puts all its dependencies on your PATH.
Notably, Systemd came up with system extensions. Seems complicated, have never gotten around to using them.
Then I look over at BSD land and their solution is stupidly simple. OS stuff goes into places like /usr/bin while user installed stuff goes into /usr/local/bin. I don’t really see why immutable distros can’t just have a normal package manager but have everything installed to a different place like /usr/local/bin and put that on the PATH.
The language used speaks for itself. We already know what “integrity” means in this context.
the company wants Linux systems to be built so their correctness can be explicitly defined and continuously verified.
This does not seem vague to me. It explicitly states what they are creating.
But how it’s implemented means everything. Google’s play integrity is corrupting because it’s designed to lock vendors in to Google’s proprietary ecosystem. You’re not getting that from this ‘language’ alone, it could be the case but it’s a massive leap at this point.
I do not care if it is connected to proprietary ecosystem or not. The freedom to decide what software am I allowed to run on my PC is important for me though. Any system that limits that freedom is evil by definition.
The freedom to decide what software am I allowed to run on my PC is important for me though
I’m right with you there, and it’s proprietary software that threatens that, nothing included in this announcement does though.
Honestly their launch announcement is so vague it could be everything and nothing.
That was my take, yes.
Treacherous Computing
I think it’s voluntary, so not quite the same.
Voluntary for developer? Sure. Voluntary for the user who can’t run software because it requires this shit? Not so sure.
I don’t think this is accurate. What Google is doing is making the whole ecosystem depend on Google’s approval to be allowed to work.
In this case, they seem to be claiming they’re just doing real-time checking of processes as they run (presumably stuff like checksuming loaded libraries, looking for memory overruns, etc.), and so detecting certain signs of malware or system corruption.
To be honest, based on the announcement it sounds completely unnecessary, but I don’t think they’re at all doing what Google is doing.
That is kinda what google does as well. It calculates checksums of certain system components and compares it to a checksum in database.
What you are describing is usually called antivirus. But they call their system “integrity”. That word is used for other things in this context.
Then I have no idea what you’re referring to by ‘what google is doing to android and tried to do to web’ because as far as I know, that isn’t relevant.
What I’m describing is definitively not antivirus. Antiviruses use heuristics (and known checksums of bad things) to scan processes/files/network traffic/system calls for dangerous patterns. They’re not doing real-time checksuming to detect system corruption or malfunction, they’re not comparing known system files because that’s complex and hard to do, and seems to be what the company is claiming here.
I have no idea what Google checksuming you’re referring to but as far as I’m aware that’s a not thing they’re doing to android and trying to do web. Everything Linux (including Android) does some amount of checksums at certain points because they’re useful, but not real-time process checksums. I assumed you were surely referring to them requiring that apps get signed by their certificates, making everything subject to their approval. Which is different from realtime checksumming for integrity.
What
Not really. Think of FIM like tripwire but for more than just userland files accessible at run level 3.
It sounds like verifying the integrity of servers to me and used by the administrator
Just to mention it: I still don’t like Systemd.
I like SystemD. I’ve found it fairly simple to use one thing to do all the basics I want, instead of 20 different programs with different config locations etc.
This is fine, and one of the strong points of a diverse software ecosystem: Chose what works best for you.
It’s vastly superior to the systems it replaced
It really isn’t. It feels fancy and like it does allsorts of clever stuff, but actually what you have is a massively over complex architecture, a non-deterministic (or perhaps a better term would be unpredictable) boot order, binary logging, excessively verbose configuration, and still some fundamental bugs in important daemons. You can fix almost all of that, but you shouldn’t have to. We had a solid, simple system before, now we have an over complex mess.
And everything it touches, it feels like it does differently just to be incompatible and extra, and like it goes out of its way to obfuscate everything to force you to use their programs to configure it rather than config files
I notice a lot of the Linux community tends to dislike things that makes life easier for users.
Binary logging is some of the most asinine shit I’ve ever had to deal with on Linux (and yes, I know you can change it, but it being the default behavior is beyond absurd).
I’m with you on that, it’s massively over complex, intrudes into systems it has no place in, and has way too many bad design choices. The designers made the fundamental mistake of wanting it to do everything okish, rather than one thing well. The worst part is that pretty much everything people poibt to as benefits could have trivially been added to tools like sysvinit and rsyslogd.
It’s probably a lost cause, and I don’t think there are many of of us left who remember how to work with the tools that embody the “do one thing, well” philosophy, or how that led to stable, predictable, and easy to manage systems.
It’s amazing that this is now a downvoted opinion.
The overall concept seemed fine, but it’s mired in some truly dogshit design decisions.
