Been having a comfy time with aeon. I like how robust it is, it just works. Kinda like tumbleweed, but even more… conscriptproof. It makes me think, maybe this is the next step in linux evolution, maybe in 2050 all distros will be immutable, and flatpak or some other way will be the primary way to do programs (cross-distro too which is nice).
(conscriptproof is when something is simple and robust mechanically, can’t be made irreparable even if you tried.)
IMO this should be in Open Chat. No request for help.
Not only “no”, but “hell, no”!
I never liked AppArmor, much less SELinux; and anything making the system even more unusable will push me over into BSD country. Seriously.
Linux is all about being open, not being locked down to whatever unusable defaults some security people cooked up. If you want others to decide what’s good for you and limit your choices, consider the Apple ecosystem.
I think there definitely is a place for immutable OSes. I’ve used MicroOS on servers, and have looked at Aeon, but GNOME is not really my thing, I can say after using it for ~1 year. Currently I’m playing around with Kalpa ( immutable with KDE, based on Tumbleweed ), 2 people I support locally are running it, and last week I got a > 12 yo laptop ( i3, 4GB ) that I installed it on. I’m pleased with how it performs and just needs zero attention.
Basically the concept is not that new ( phones, tablets, Chromebooks ), but immutable desktop distros are relatively young. IMHO Aeon and Kalpa are on the right track by not reinventing the whole OS, but basing on an existing tested rolling OS. Install once, and let the system keep itself rolling.
All that said, is it the Holy Grail and will everything be immutable in 2050? I am no clairvoyant, hard to tell. Will we be able to buy devices with a preinstalled immutable OS? No doubt.
With systemd-sysext, containers, flatpak (hopefully soon OCI) it will be easier.
I was quite surprised to learn about systemd-sysext here systemd-sysext.
However, if you don’t have a burning desire to be on the forefront of this, its the same just slightly tighter… All these constructs are just 1 security issue away from being worthless… God forbid you ran this command on your apparmor system a short while ago;
`su whatever 2> /sys/kernel/security/apparmor/.remove’ [1]
So basically full commonality of internal parts across the distros that want this? Interchangable, built to the same tolerances etc etc (some manner of regulatory board for keeping those standards somewhat same across the industry?)
I have thought of installing an M.2 SSD into a little-used laptop to experiment with Kalpa. The main obstacle for me is that I think Kalpa expects the btrfs file system. I can use Clonezilla to reliably clone my ext4 Tumbleweed partition, but have read that Clonezilla doesn’t function reliably with btrfs. I found alternatives, like that described at https://github.com/mwilck/btrfs-clone#alternatives, but they would be new for me.
(I’m not asking for support on this backup issue, BTW. I likely would need support if I were to ever get around to this experiment, but for now have no firm plans.)
Shundhammer, I read on this forum last week that you were on the Yast support team for thirty years. (!) You’re much, much more knowledgeable than I am as a Linux user, and better able to protect yourself and insure that your set-up is 100% secure to use. I think an immutable system like Kalpa could offer security benefits to a run-of-the-mill John Doe user like me.
As somebody who is making a transactional desktop, I can assure you, that I do not, and will not ever argue for the replacement of Tumbleweed with a transactional, image-based, or “immutable” version by default.
They have their place, just like a traditional package based, read-write root linux install does.
In that case, Shawn, as it’s the transactional desktop that you’re making that so appeals to me: do you think an immutable desktop like Kalpa can be inherently more secure for a non-expert user like me than a distro like Tumbleweed? Or is the user who doesn’t go out of his way to mess things up as safe with Tumbleweed as with Kalpa (at least if that user is careful about adding repositories, which seems to a consistent Achilles Heel for some)?
@Tuner you don’t add anything to the base system if you can help it, distrobox and flatpak as your user…
A transactional or image-based system can help save users from themselves, yes. But “additional security” is not an explicit design goal for Kalpa.
Any gain in security is mostly indirect, as a transactional system does reduce your attack surface in many ways:
Less root privilege actions, via RPM installs of things into the system root (RPMs are always installed with root privileges, by default, and its possible to insert arbitrary code into an RPM spec, that will be executed on install. That being said, particularly from “trusted” sources like the OSS/Non-OSS repos, this really isn’t a concern, but it is possible depending on where you get your RPM’s from)
Containerized applications, without elevated privileges, via flatpaks (The flatpak sandbox mechanism is not perfect, and causes some problems, with some workflows, but escaping that sandbox is less likely to result in a privilege escalation locally)
Services delivered via rootless container (via distrobox/podman) again, this is not perfect, and you can get privilege escalations, if you’re not careful, but by default this is more difficult. Of course, you shouldn’t be using Kalpa (or frankly, as far as I’m concerned any sort of desktop focused linux recipe) as a “server” for any kind of long term service delivery method)
Kalpa isn’t put together with “Security” in mind as a primary decision for how things are done, but the nature of the transactional system, and the privilege separation between the “System Layer” and the “Application Layer” can reduce the attack surface, and provide a more reliable, stable, and secure system for folks that aren’t interested in making their desktop a full-time administrative job.
But that does mean that there is an implicit trust given to Me as the developer, that I’m making security and design decisions for end-users. And I’m not perfect.
Maybe, when talking about “security”, one should make his mind and tell what he expects:
Thanks for the feedback, everyone. (And Shawn, I’m especially grateful for so complete an answer from the developer!) I’ll let the forum know if I follow through with Kalpa on the M.2 SSD in the laptop. For now, I have time to post, but not the full day I’m guessing that I’d need for the experiment.
The install on mentioned 2012 laptop took ~1 hour, using the Kalpa_Desktop.x86_64-Offline.iso installer.
I’m working on that. granted, it’s somewhat hardware dependent, but getting ~5GB of stuff written to disk shouldn’t take an HOUR, not even on 2012 hardware =P
It actually was pulling in newer packages from the repos, I could see that because /etc/os-release gave a date from after me downloading the ISO.
Thank you. Well there’s always the need to trust the devs, anyone can get hacked or sidelined.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.