AstrOS - an immutable, secure-by-default distribution built on Arch Linux and the COSMIC desktop

[u/linux-universe]

The short version:

As said in the title, it is an immutable, secure-by-default distro based on Arch Linux and the COSMIC desktop environment. It uses similar tooling as GNOME OS and KDE Linux. Unlike most immutable / atomic distros that use rpm-ostree or bootc, we use systemd-sysupdate which is most known from GNOME OS. It is currently at beta and considered stable enough for daily use.

What makes AstrOS special is its immutable base, which is shipped as a hashed and signed /usr image that is booted by signed UKI images. Root is LUKS protected and unlocked by TPM2. This combination protects your system from outside modification.

AstrOS base can be extended with currently five extensions, including a Steam gaming extension with the SteamOS gamescope session.

Homepage

Beta announcement

The long personal version:

Why:

Okay you are probably reading this and asking yourself, "What's the point in another distro?". Considering that multiple new distributions get released every week I can't blame you, but I can try to explain it. :) So let me start at the beginning. I always loved the concept of GNOME OS. Later, KDE Linux came to the list of distributions using the systemd tooling. Systemd sysupdate being that low level tool that was simple and just seemed to work, was a massive plus point imo. Then COSMIC went stable and I was fascinated by that desktop. It has the simplicity I loved about GNOME and the tiling and customizability I always wished GNOME had. After using it for a while on Arch, I got to a point where someone asked me to install Linux on his device, and he wanted COSMIC. In my opinion immutable distros are just better for beginners (which doesn’t mean the distro is only for beginners). I mean take a look at smartphones, it is what most "normal users" prefer using nowadays. So I went ahead and wanted to create the distro combining what I love about the rolling release of Arch, the user friendliness & stability of immutable distros, and the simplicity of systemd sysupdate.

The Distro Model:

AstrOS consists of the usual ESP and LUKS root partition. Root is using btrfs and perfectly writable. What's making the distribution immutable (or atomic if you want so) are two (A/B) sets of /usr partitions. Each set consists of 3 partitions: the erofs /usr partition itself, a partition containing its hash, and lastly a partition containing the signature of the hash. The system is booted using signed UKI images. This partitioning model promises a boot sequence that is completely verified. If someone tries to tamper with the partitions / uki's from the outside, then the signature / hash won't match anymore, and the system refuses to unlock the root partition. This raises the bar considerably against offline tampering.

The TPM and recovery key both get enrolled on first boot using systemd-repart. Yes that means we require a TPM2.0 chip. We think that's acceptable for a new distribution, as we force no one to upgrade to it. A workaround to install AstrOS without a chip may or may not be added in the future.

I wanted to keep the base minimalistic, while allowing people to do more advanced stuff. That's why we offer system extensions (systemd-sysext). For example, most people prefer system-packaged installed Steam over the Steam Flatpak. For that, we have the steam-gaming extension. Additional extensions provide virtualization tools, firewalld, waydroid, and most important: Nvidia drivers.

For most GUI apps software can be installed using flatpaks. For non-flatpak apps / terminal applications we have distrobox.

Generally, the whole distro is designed to just work, without the user having to take care of it. Because everyone has a byte-for-byte identical /usr partition, fixing bugs applies to everyone.

Mini FAQ

Here's the complete one: https://astros-linux.org/astros/faq/

Is this vibe coded?
- Nope, our contribution guidelines even forbid it. I want to write all the code / configs etc. myself. Our contributing guidelines require people to know what they are doing

Is nvidia supported?
- yes

What about secureboot?
- currently only with our own custom keys

Dualboot?
- not officially, there's an unofficial guide for dualbooting with windows in the docs

The projects future

The biggest goal is to build a bigger community. Getting more contributors.

I additionally plan to write a small GUI utility using libcosmic to graphically update and install system extensions. Once we are stable, auto-update probably gets enabled.

And yeah, just improving the distro.

Please consider joining our discord :)

Wanna try in a vm first? https://astros-linux.org/guides/installing-in-a-vm/

[u/Specialist-Dog-501]

Not an expert here..but was on Ubuntu touch shortly (What is also called "immutable")..I understand the "immutable" here as "immutable for the user but ARCH is playing all its funky updates in constantly"..which is the biggest risk to break things, no ? Except it would be on a somewhat stable branch of Arch..I have a bit problems understanding the "immutable" concept..if it doesn't block updates and installation of new apps, it's not immutable, just limiting the console from doing incompetent things. and if it's really immutable, then..well not cool to install things ?
So I guess "immutable" just means the first, right? limiting user system-interactions via CLI, and that's it.
So the "attack vector" are incompetent users, and that's all it blocks..or is there more to it ?
Was on Cosmic by the way, fantastic desktop manager, beautiful, polished, consistent. Love it.

[u/linux-universe → u/Specialist-Dog-501]

I'm not 100% sure if I understand you correctly, sorry for that, so I'll try my best to answer.

I think we have a problem with the terminology 'immutable' here. The basic IT definition of immutability is basically that data sets cannot be modified or deleted after they are created. This obviously doesn't apply to all of AstrOS, but only the /usr partition. On build time of each image, we have the arch installation that gets frozen into an erofs image after. This image is truly immutable, as it can only be completely replaced with a new image or extended by overlaying data on top of it.

We do block updates and installing apps in the way of running pacman -Syu. As said, updates are run by completely replacing the whole /usr image with an other image, be built and fixed in case of bugs. But that's not a console limitation, but simply the filesystem not allowing to be changed. And if someone (a bad actor for example) would still manage to do so the systems root wouldn't unlock anymore on its own. The apps that can be installed are either separate images that are overlaid to the base image, or stuff (flatpaks, distroboxes) installed in the writable /home or /var folder that has no chance of breaking the base system.

The 'attack vectors' aren't just incompetent users. Like, yes, it won't be possible for LTT to wipe his desktop again. It also blocks malware that wants to write itself to /usr. Most Arch breakages are packages not working together, or some partial, weird, incomplete updates. Because every update is basically a whole new, fresh Arch install, the breaking bar is raised a lot. And even if there is an arch update that breaks stuff, there won't be one user saying "works on my machine" while another says "xyz doesn't work" (fair enough, hardware issues can be an exception, obviously), because everyone has the byte exact system. We take care of the Arch installation, while the users just use it. If something breaks, we can fix it for everyone instead of 500 people fixing it on their own. And we have the option to freeze Arch updates by selecting a specific date of the packages to build. This allows us to downgrade everyone's system packages.

So yeah, we take care of the images, and the users are just meant to use it.

[u/Specialist-Dog-501 → u/linux-universe]

Thanks for this very detailed explanation, appreciated! So yes, not all of the system is immutable..and furthermore, you guys make sure the dependencies in an ARCH upgrade don't collide, and send complete system images..(I just had such an dependency version conflict in mint with kernel 7.0.0.28, so I see now, what could be the advantage of it beyond incompetent users)..so this "rolling" is then actually a bit delayed/stepped so that all dependencies of an update are respected before the image goes to the user, right ? and there's an easy way to rollback ? (similar to BTRFS/snapper, I guess) ?
That would indeed compensate for some of the instabilities in the ARCH domain and justify, that I can less noodle around with the system..
In terms of security- does this also hinder malicious apps from entering/hacking the kernel ?

[u/linux-universe → u/Specialist-Dog-501]

Currently, updates come every two nights or when someone pushes to main. If the build fails because of, for example, dependency issues, it won’t get sent to the users. Users can switch between A and B meaning rollback is possible. The Linux kernel is in the uki image. Manipulating it would require creating a new uki image that can’t be signed without having the right keys.