openSUSE Aeon (formerly MicroOS Desktop)

Site Development Tool Suggestions
21

I am back after nuking and paving my daily driver for MicroOS and here are my impressions:

It is a release candidate and still honestly feels like beta. I was expecting some basic power saving measures and hibernate function because I was going to use is as my daily driver for my laptop but it did not have those features ready yet. I closed my laptop lid and it did not turn off the monitor. I realized only this after about 4 hours with the screen on full brightness. It shouldnt be an issue but I have an OLED screen. When I came back, I tested my suspicion and I could still see the light shine through a bit on a closed screen lid in a dark room.

There was also no fingerprint support off the bat and while it is probably more secure not have a fingerprint registered in a sensitive device, having to type a long password/passphrase everyday on a daily driver with no fingerprint alternative would be too much of a usability problem.

All in all, OpenSuSE Aeon feels like 2 tiers below Fedora and Vanilla Ubuntu respectively. I really want to use it but the polish isnt there yet. I switched to a regular Tumbleweed install and above issues still persist. There was also the minor annoyance of learning the right way to update. There are a lot of alternative ways to update a system and I am not aware if what is the preferred one (its probably zypper).

Also about zypper, I really didnt want to learn another way to update: we already have apt-get, apt, dnf, pacman, pamac?, etc… and I realize OpenSuSE also uses the RPM and I wonder why they couldnt use the dnf instead? I am guessing the F in DNF is Fedora, maybe?

I dont exactly know how to layer the Aeon/MicroOS Distrobox install over an app when I wanted to install something, to be fair, I really didnt try but Fedora Silverblue seems more straightforward - I just ran the .rpm file and it did install it on top of Silverblue.

It feels like installing and updating is all over the place: Too many GUI apps to update and the experience is less that cohesive. We have 2 different kinds of GUI apps to do things and I feel like it should have been consolidated with the Software Center like how Fedora and Ubuntu does it.

I also dont even know what YaST is for and I am tired of the random lower case in the naming convention of OpenSuSE products. At least System76 only have a weird name only in its title of Pop!_OS.

As for the plus:

  • I believe the OpenSuSE installer is probably the best at striking a good balance between usability and customizability. The only weak point in the installer is when I want to use a more complicated partitioning and somehow I am having a hard time to translate what I want to happen and what had to do. In the end I just opted for a plain recommended autopartitioning.
  • There is also the option of choosing your DE/WM in the install instead of downloading a separate KDE or GNOME (or other DEs if you have internet access during install) and you can even install a MicroOS system from a regular Tumblweed install.
  • I was really able to put most of the apps - flatpaks and AppImages that I needed in the end of the exercise to have a technically functioning system to do work with.

In summary:

With the recent drama dying down and the focus going back on the worse of the Tech companies rather that RedHat. I want to go back again to OpenSuSE in the future and maybe give it one more good go in trying to daily drive it. Right now it is not a good laptop Distro with the above reasons (hibernate and fingerprint) but maybe it is a good desktop replacement for Fedora and maybe replacement for Silverblue. Maybe this is OpenSuSE Tumbleweed/Aeon may be fit for a small PC form factor (like a NUC) install? Despite as being an enterprise grade distro along the lines of RedHat and Canonical, OpenSuSE feels like it needs more polish and maturing and I dont know if this is due to a smaller base relative to all other Distros, not just the enterprise ones. Only time will tell. At least I am now more tuned in to them.

1 Like
22

Is it possible to install a VPN client with the .deb package using distrobox and route the whole system’s traffic to the VPN without any problems like in traditional operating systems?

23

I was not able to get that to work but it could have been just my specific VPN provider’s app.

24

VPN and video drivers need to use transactional-update because they modify the system, distrobox does not work.

1 Like
25

Thanks for the answer. Does this method not work because the OS is immutable, or because applications installed with distrobox cannot modify the system even on traditional operating systems (e.g. Tumbleweed, Leap)?

26

Applications in Distrobox cannot modify the system I think. I got some error relating to resolv.conf when I tried to install the VPN .deb in the Distrobox.

You can still install VPNs on immutable systems via transactional-update (openSUSE) or rpm-ostree (Fedora), but the VPN would need to be available as an RPM package.

1 Like
27

The Silverblue FAQ states that the etc directory is not part of the immutable system. If it is the same for MicroOS, if etc is not part of the read-only immutable system, I think the VPN client application will actually work. I know distrobox is not a container that provides isolation, sandbox. If it is not a nickname similarity, it seems that the distrobox developer gave you a similar answer in the link below.

28

Yes you’re right. However, my specific VPN provider* didn’t work even in a rootful container. I guess it depends on how well-designed the app is. I mean there’s even one VPN (ProtonVPN) that’s available as a Flatpak.

'* not a particularly good or private VPN provider, I just got a cheap lifetime deal many years ago and it’s still working so I’m not going to switch

29

Worth noting that the option for full-disk encryption is planned to be removed on Aeon (and likely Kalpa), in favor of something more “user friendly”. FDE is currently a requirement for distributions to be listed here.

Edit: Changed link to Wiki instead of matrix chat. Original link

1 Like
30

this is informative and unfortunate

1 Like
31

This is concerning, both because of the decision itself, but also the general approach to security it speaks of.

However, users need to have a secure Linux desktop, so we’ll be using systemd-homed by default to ensure that every users home directory is securely encrypted.

Is this in any way an adequate replacement? Can anyone explain in some more detail how security would be impacted?

32

There’s some explanation

However, users need to have a secure Linux desktop, so we’ll be using systemd-homed by default to ensure that every users home directory is securely encrypted. Not even root on a potentially exploited Aeon machine will be able to change a systemd-homed users encryption key.

This should also bring additional benefits including

  • Support for FIDO2 as a second factor for user authentication
  • User + Home directory portability, which is additionally useful in the event of resetting/reinstalling Aeon machines
  • Forgetting encryption keys as system suspend, further improving security in a Laptop context

It does bring some complications

  • Storage management will be slightly more complicated than ideal, as the encrypted loopback device will need to be allocated space and managed appropriately. homed will do much of that automatically, but even at it’s best it doesn’t scale wonderfully. However, given most laptops are realistically to be used by 1-5 people most, this shouldn’t be an issue
  • SSHing into an homed user will be much harder/impossible to support, as the user will need to be decrypted with the passphrase before SSH can read the key information. Given Aeon should be the OS you SSH FROM not SSH TO this is probably not the biggest issue
  • Some tooling like gnome-initial-setup will need to be modified to work best with homed, which may cause some rougher edges than ideal for a while

And I kind of agree with this. I stopped using FDE on desktop PC, and even on portable computers (steam deck) I could live without it, as long as my private files are encrypted (Cryptomator or KDE Vault). Though I do have it now on laptop with openSUSE

1 Like
33

File-Based Encryption is theoretically just better than FDE, as Android and iOS have proven… The general problem with it on Linux specifically is that verifying the non-encrypted portions of the disk (i.e. the system) haven’t been tampered with while the system is powered off is challenging.

FDE prevents physical, offline attacks, and FBE has all the advantages they covered in the explanation above, but it alone doesn’t really address the same thing as FDE. This is why we usually recommend FDE and FBE like Cryptomator, systemd-homed, etc.

I’m not sure how robust MicroOS’s secure boot implementation is to circumvent this issue?

34

Regarding openSUSE Aeon, I would like to add that as a Tumbleweed user, I don’t see any point in moving to Aeon at all. As a desktop user, I think it might be less secure for me too, due to fewer official software sources available/compatible on the system, i.e. it doesn’t support Snap, and AppImage is not supported out of the box. That’s a lot of official apps out there.

The recommended software source on Aeon is Flatpak, but it’s not there yet, as some major apps on Linux are not supporting it (yet), for example, Blender, Inkscape, VLC, all the Chromium-based browsers, IVPN client, in which Blender and VLC officially maintain Snap, while Inkscape officially maintain AppImage for non-Ubuntu users, and Brave officially maintain Snap, though not recommended. Big cooperations, for example, Spotify, Flutter (Google), Skype (Microsoft), support Snap, not Flatpak. I can’t list them all.

If the users can’t find their apps in Flatpak, it’s recommended to install their apps in Distrobox, which might not fully compatible with all the apps. Some apps might not run at all. And the process of installing apps through CLI, also with dependency hell issue, is clunky at best.

Most users who gave up with Distrobox, then fall back to transactional-update, or to Tumbleweed entirely, as you can also use Flatpak and Distrobox on Tumbleweed just like on Aeon. Then, you won’t mutate your OS ever again, assuming that your workflow/usage can survive with only Flatpak and Distrobox.

Auto download and install updates? Yes, I do this on Tumbleweed as well with GNOME Software, no need to use Aeon. What about bad updates? Yes, I have snapper and rollback system in place by default on Tumbleweed.

The issue about all immutable OS is that the users believe that they can install unofficial Flatpak apps and call it a day since apps are sandboxed, which is not true, as it’s up to the packagers to set those permissions. The most noticable one is filesystem=host. Flatpak also doesn’t prompt any permission request to the users like Android or iOS does.

With the current form of Aeon and the overall packaging situation, I would rather choose official support from devs, security-wise, over immutable things from the OS.

2 Likes
35

I agree with you. I was also TW user (swtiched to Leap & Kubuntu), and have been testing Aeon a bit. First I was surprised to see AppImage is not supported and Richard confirmed it will stay that way. So I realized if I would like to keep minimal number of programs installed from repos, I could still use Tumbleweed and install (only) snaps, flatpaks & appimages.

I see these kind of distros useful for less experienced users (who would still need support when needed program is not available from the official package manager) and maybe (small) business

36

That’s a very interesting point. Would you bring the same argument against Fedora Silverblue/Kinoite, as they also don’t support Snaps (though I think AppImages should work)?

(I guess the main benefit of an immutable system for me personally would be the ability to roll back updates, but Tumbleweed & Leap already support that anyway.)

37

I haven’t tested it myself, but you might be able to get Snaps to work. But it will be without Apparmor’s confinement, since Fedora’s and Suse’s immutable spins use Selinux, which basically makes Snaps unsandboxed.

Snaps are far from perfect, but way less of the confined apps have trivial sandbox escapes, while on Flatpak - without manually adjusting permissions -quite many do. And I have found way more of my apps with official packages as Snap than as Flatpak. Another advantage is that Brave’s and Firefox’s sandbox was fully functional and unmodified, last time I checked, which isn’t the case for browsers as Flatpak. There are also a few downsides, for example Snap fell through Suse’s security audit.

38

I have no experience with Silverblue/Kinoite, so I can’t tell. I tried Fedora 36 for 3 months, but it’s not my cup of tea, too much hassle to set up a stable system with snapshot and rollback system in place. Therefore, I went Tumbleweed ever since.

Nevertheless, if Silverblue/Kinoite doesn’t support Snap, I would express the same argument I have with Aeon against it.

I can’t understand why these immutable distros ban Snap. Sure, Snap has some security concerns against it. But why don’t they place the same concern against .rpm packages then? Compared to Snap, those packages have no sandbox or whatsoever. To me, it’s more like a political move than a technical perspective.

As a user, I am concerned about security that all apps should come from the most creditable source (official channel from the app devs) whenever it’s possible. I don’t care a bit about Snap’s political nonsense. I will happily use Snap, Flatpak, AppImage, or whatever, as long as it’s from the official/verified app devs. The OS should not interfere with that, especially if the users are put at another/even more risk by that interferance.

39

I don’t they they “ban” it per se, it’s just that the /snap folder can’t be created if the root partition is immutable?

40

If they wanted the /snap folder to be mutable just like /etc and many others on the root partition, they could. So, I don’t think this is a technical limitation, see here. I don’t know if this will work on Aeon, though. My point is it’s not impossible to support Snap on an immutable OS, technical-wise.