SystemD's Creator Opens Signups for Private Preview of Amutable's Cryptographically Verified Linux Systems (itsfoss.com) 47
SystemD creator Lennart Poettering left Red Hat for Microsoft in 2022, but 10 months ago left to co-found Amutable a company that aims to build cryptographically verified Linux systems that stay trusted over time.
It's FOSS calls it "a read-only, image-based system where every machine produces signed reports of its own state" — and signups are now open for a private preview: Before announcing this Linux-based implementation, Amutable had released two open source tools. tine, a Buck2-based build system that composes OS images; available under MPL-2.0, and Quarry, a TUF-based tool that distributes those images to machines; available under Apache-2.0. What Amutable Foundations brings to the table is a service where Amutable runs the images, update repositories, control plane and vulnerability fixes for organizations and individuals who operate their own systems.
No license has been stated for those company-run parts, and the preview announcement does not say how much of Foundations beyond tine and Quarry will be open source. Software and configuration both ship as signed images, and a machine boots only what is signed. Because there is no package manager and no SSH or interactive shell, a change means giving every machine in your fleet a new signed image.
Its images are reproducible, come with a software bill of materials (SBOM) and are built from pinned inputs of whichever distribution you pick, with tine being able to import packages from Fedora or CentOS Stream. Each machine sends a signed report that records what it booted, from the firmware and boot loader up to the kernel and OS, plus the configuration it runs... Amutable's control plane verifies reports from systemd-report, an experimental command in systemd 260 that the company helped build. It compares each one with the declared state and flags machines that deviate. A rollout only continues while machines can show they are in a good state...
Amutable is signup formlooking for teams that manage Linux fleets and need to show what state each machine is in. It expects to start bringing the first 'design partners,' as it calls them, on board over the coming weeks.
It's FOSS calls it "a read-only, image-based system where every machine produces signed reports of its own state" — and signups are now open for a private preview: Before announcing this Linux-based implementation, Amutable had released two open source tools. tine, a Buck2-based build system that composes OS images; available under MPL-2.0, and Quarry, a TUF-based tool that distributes those images to machines; available under Apache-2.0. What Amutable Foundations brings to the table is a service where Amutable runs the images, update repositories, control plane and vulnerability fixes for organizations and individuals who operate their own systems.
No license has been stated for those company-run parts, and the preview announcement does not say how much of Foundations beyond tine and Quarry will be open source. Software and configuration both ship as signed images, and a machine boots only what is signed. Because there is no package manager and no SSH or interactive shell, a change means giving every machine in your fleet a new signed image.
Its images are reproducible, come with a software bill of materials (SBOM) and are built from pinned inputs of whichever distribution you pick, with tine being able to import packages from Fedora or CentOS Stream. Each machine sends a signed report that records what it booted, from the firmware and boot loader up to the kernel and OS, plus the configuration it runs... Amutable's control plane verifies reports from systemd-report, an experimental command in systemd 260 that the company helped build. It compares each one with the declared state and flags machines that deviate. A rollout only continues while machines can show they are in a good state...
Amutable is signup formlooking for teams that manage Linux fleets and need to show what state each machine is in. It expects to start bringing the first 'design partners,' as it calls them, on board over the coming weeks.
Thanks, I hate it (Score:2)
pass
Seriously, can't this guy just GO THE FUCK AWAY? (Score:5, Interesting)
Fuck Lennart.
Fuck systemd.
and tangentially, fuck Microsoft as well.
You know how long it took after his paws were no longer all over PulseAudio before it got to be halfway stable and usable for daily driving? Both Amutable and Quarry may AT BEST eventually follow that trajectory, but goddamn, systemd is still a gigantic piece of shit that the primary features it provides are 1) a gigantic attack surface, and 2) a great many potential modes of failure. Anything this guy has been involved with should BY DEFAULT be treated with suspicion and the architectural choices beaten on with a hammer.
Re:Seriously, can't this guy just GO THE FUCK AWAY (Score:5, Funny)
He touched him on the systemd, obviously.
Mother fuck Lennart Pottering (Score:1)
Re: (Score:1)
Re: (Score:3)
Yeah, no. I don't like SystemD any better than anyone else, especially since I just spent three weeks converting a bunch of third-party SysvInit scripts to SystemD (and I'm still not 100% sure they work perfectly), but I still can't agree it was a solution in search of a problem. Like it or not, SysvInit is amateur hour. I was shocked that Unix worked that way when I started using it in the 80s, and that it took s
Re: (Score:2)
Re: (Score:2)
If no one follows the standard, does it really exist?
Re: (Score:2)
Re: (Score:2)
The guy reinventing windows went to ms? (Score:1)
Inconceivable!
new revenue stream (Score:5, Insightful)
this sounds very much like someone sitting down and thinking "... how could I make a thing which nobody wants but requires some centralized signing and distribution layer which I can charge $$$ for".
I mean -
"a change means giving every machine in your fleet a new signed image."
Very much in keeping with Poettering's other work, the ends justify the ends.
Re:new revenue stream (Score:5, Insightful)
In a closed ecosystem, not sign it with your own key? Only your own devices will be able to verify that signature, and that's fine.
It doesn't have to be centralized in a way like MS Authenticode is (where you need a certificate from a "blessed" CA).
Re: (Score:1)
Even better than that, just use the TPM that everyone has anyway. Put your keys in there, and let "Secure Boot" operate the way it's intended.
Re: (Score:2)
It's even stupider than that.
You can already do a read-only immutable file system. Embedded systems and avionics already does that, and specifically in avionics it's a design mandate. But we sure as shit don't want to run a full reimage on an LRU while the tail is on the ground for 40 minutes with weight-on-wheels and the flight is closed. That doesn't work.
The irony: systemd fixes this with sysext / confext primitives. We can push new images to /var/lib/extensions-available while in the air, and they b
Ignoring the hysteria... (Score:3)
Re:Ignoring the hysteria... (Score:4, Informative)
Well, Debian has signed updates. I assume most other distros do. I'm not clear what the benefit of this is. Who are you going to trust to do the signing? Does the entire system need to be resigned after every update? At first glance this only works if your entire system is in one "file", and you sign that file with a unique signature. But who's going to know what the proper signature is?
Signing individual packages seems much more reasonable. Then two people can compare the signatures on a particular piece of software to determine that they are the same. (But for that, why rely on signatures when things like sha256 exist...unless that what they mean by signature, in which case the prior caveats still apply.)
Re: (Score:2)
If I wanted an OS that was read only for security reasons I would use media with a physical switch that prevented writes. The signed reports sound like the dbus systemd log files that are 99% noise and 1% relevant.
Re: (Score:2)
And btw., "read-only" Linux is a pretty old idea, remember "Knoppix" [wikipedia.org] 26 years ago? - Its author wasn't a pretentious megalomaniac.
Re: (Score:2)
But it's pretty obvious that this Amutable crap is just an attempt to sell a security model that is unlikely to work in practice. I'm sure it'll attract enough VC money to allow them to cash out nicely, though.
Re: (Score:2)
This is a thought experiment. I could also have phrased it as 'imagine someone else released this' (Linus, for example!).
My question is whether or not that would be something worthwhile, or is this whole concept not really useful? I don't know the ins-and-outs of it, but if it's an attempt to provide signed binaries, and includes making a compile
Re: (Score:2)
IMNSHO, something like this could be useful for IoT devices and similar systems. One often doesn't want a full OS on them, or SSH access, or the overhead of a package management system on the device, etc.. But will this bring any significant improvements over their existing update methods? From what I've seen of those random devices, there's certainly room for improvement.
The other area I could see this being useful is in VM[^1] deployment, especially with orchestrated systems that spin up and down VM's lef
Re: (Score:2)
Re:Ignoring the hysteria... (Score:4, Interesting)
I could maybe, depending on what it actually _is_, seeing a use for something like this for networked embedded devices like the kind you see in industrial or utility setups. Think power grid, water system, or other industrial monitoring... situations where you really don't want to to take the device's word that it isn't comprimised.
Re: (Score:3)
It's possible TFS is over-simplifying the design of the new system, but - why no ssh and no package manager? Why not make the underlying OS signed and immutable, but still allow stuff to be added / saved / deleted in userland? I'd think that would make for a significantly more user-friendly system with arguably only small security tradeoffs.
Sort of a cross between SELinux and macOS' security model, I suppose (and really Leonnart's ideas always seem to be riffs off macOS anyway).
Re: (Score:2)
Sure - it does for the OS what puppet does for configuration.
I was at a Wendy's during a big data center outage and all the kiosks were down.
For some reason their down state is to drop to Windows Explorer. I found it interesting that they were managing their international fleet of probably tens if thousands of terminals using puppet to ensure deployment consistency.
The filesystem didn't appear to be readonly to the kiosk user, though I didn't test that. (have some sympathy for IT guys)
This new project cou
Re: (Score:2)
Everything this summary is talking about is already available to do with Debian, and can be done better with Debian.
I don't want to build a monolith image for if some tiny config change or patch is needed. This is why systemd sysext / confext exist.
Extra irony that this is already solved by systemd, and this guy is trying to answer a question that his previous project already answered, and answered better.
Resistance is futile :o (Score:2)
The systemd people have at last delivered the secure operating system they always promised. I
Re: (Score:2)
All this.
The systemd people have at last delivered the secure operating system they always promised.
By this, they mean locked down.
From TFS:
Because there is no package manager and no SSH or interactive shell,
So, pretty much useless in most environments. And for people who are doing their own development, do you really want to give Amutable/Poettering a peek over your shoulder and possibly veto power over your project? Anyone that didn't see this coming in the early days of systemDunce deserves everything they get.
Re: (Score:2)
This would have been useful 10 years ago in certified embedded systems development. But it's not 10 years ago, and basically everyone in that realm is already doing this with regular Linux distros that don't have boutique publisher problems.
What would cause me to move from Debian to this monstrosity, when I can already make a read-only root with crypto attestation and use systemd sysext / confext to plug in things / remove things without changing the root filesystem per certification requirements?
This is a
Re: (Score:3)
SystemD people finally building the secure OS they always talked about.
It's not secure.
Overcomplicated crap (Score:5, Informative)
Keep code simple so users can easily understand what is going on.
It is same story with WebDev. I don't understand what was so hard about JS, that people made all this bullshit like React and Angular. We had jQuery and it was glorious. There was no need to make it the module and import hell it is currently.
Same with PHP. People seem to forget that PHP is a JIT language with some code caching recently being bolted on. Write bare metal code just to serve the dynamic parts of an HTML, is the correct way to use it. There is no need to serve static content via PHP. But people do that everyday with whatever the latest framework is.
Re:Overcomplicated crap (Score:5, Interesting)
The simpler something here the harder it is to make a mistake in its implementation, and the smaller its attack surface. This has always been important but I think there's a fair argument to be made that it's more important than ever now that LLM-driven attacks are a thing. It will be interesting in (let's say) five years to survey all of the LLM-originated vulnerabilities and ascertain what software was most/least susceptible. My guess is that -- as a first-order approximation -- it'll be linear with the number of lines of code.
SaaS? (Score:3)
IANAP, so please tell me if I'm off base here: to me this has a flavour of SaaS. FTA:
We foresee, and are building for, a future where it will be standard practice for Linux machines to be able to prove their state and for access to depend on that proof. Infrastructure that can't prove its state will look like unencrypted network traffic looks today: still around, but only for toy use cases.
Replace "Infrastructure" in that last sentence with "A computer connected to the internet", and it seems to me that you have a situation in which the machine I'm typing these words on might be refused access. I know that's not true in the current description, but it wouldn't take much scope creep for many people reading this to be unable to do what I'm doing right now.
I suppose they might consider me a "toy use case", but again, scope creep or regulatory overreach might turn that into "forbidden use case" on a whim.
Does it come with SystemD included? (Score:2)
I'll pass.
Trust (Score:5, Informative)
Are we really going to trust something security-oriented by a guy who conceived of systemd? Instead of creating something which improves security and isolation, he created something renowned for its architectural and management complexity, privilege boundaries (or frequent lackthereof), attack surface, and the frequent consequences of concentrating system management in a large privileged software stack.
I'm reminded of the SSH/Pulse Audio privilege escalation through systemd some years back... due to their obstinately poor security design.
Re: (Score:2)
Seems like a waste of time. (Score:2)
It will probably only function with an active network connection, and all of the garbage applications that L.P. has on his laptop.
Confusing signatures with trustworthyness (Score:2)
Signed code is not necessarily trustworthy. There is signed malware out there. Look at the mobile world, where everything is signed, but nothing is secure. (in the sense that it protects user data)
It's solving the wrong problem.
However there's a dark side to it. We have governments and companies trying to pass laws on how computers can be used. Having enforced signatures makes it easy to enforce such things.
Immutable Linux And Atomic Updates (Score:2)
I understand the vision for immutable** Linux and Atomic updates. It seemingly "makes sense" for security and consistency sake. You wind up with a virtual appliance. It's rather akin to firmware, rather than open software.
You can already do this with several upstart distros and even optionally heavy weights like SuSE and Debian.
I do appreciate that Poettering is doing this with his own company and that using his distro will be a customer's choice rather than somehow forcing this on all Linux users. I wish h
Re: (Score:2)
Thinking about this. As I poke away at my Android tablet. It's not really a strange position to take. My tablet, my TV set, innumerable appliances around my house, kiosks all over town.
Turns out that there's already an 800 pound gorilla that owns this space. Google. I wish Amutable and Poettering good luck in this market.
"Trust", yea right (Score:2)
The only trust here is that software makers want to trust that they have more control over your devices than you do as the owner of them. Thats a huge fuck no for me.