Micro OS/SUSE Aeon compared to Fedora Silverblue

English Install/Boot/Login
#1

I haven’t used Aeon or Silverblue as my daily driver yet. I just experimented with it in GNOME Boxes. I know Aeon is still a release candidate and not released as a stable version yet, but I see some interesting differences between these two.

  1. Silverblue has rpm-ostree reset, which removes any customization to the overlays. This is a great feature, because it allows you to go back to the original intended setup that Fedora maintains and tests. Any customization should be minimal, just like with Aeon. However, it doesn’t look like Aeon can do this. Silverblue uses some kind of GitFS, where changes are tracked and you can rebase to a certain branch. Aeon seems to have a wrapper to install RPMs into a btrfs snapshot which you can then boot in order to use it. Therefore, both have the transactional update mechanism, but Silverblue seems better? Because you can do this reset, where you revert any changes and use what Fedora has released and tested. With Aeon it seems like it’s easier to divert from the original setup. There is no reset option. This reset option is great since it allows you to clean up your system, without doing a reinstall.
  2. Silverblue has firewalld. I read that Aeon doesn’t have any firewall because it messes up container setups. But Silverblue has the same philosophy of using containers and Flatpaks. I don’t like to use a system that doesn’t support or provides a firewall. Is Silverblue doing something wrong or right compared to Aeon? Or is this something that will be fixed when Aeon becomes stable?

Now I know Aeon has snapper and rollback, but that’s not the same as cleaning up any mutations you made over time. That’s just going back in time, and maybe even reverting your /home files? Anyway, I’m seriously looking into Aeon, it looks promising. The recent Red Hat news have made me look around for alternatives. I really like seeing SELinux in SUSE and the clean install!

Tumbleweed remarks

Tumbleweed comes with a very bloated install which is even a hassle to correct in the installer. Deselecting stuff still results in a messy install. I don’t get the default package selection. It’s also a pain to get rid of YaST. I know SUSE users love it. But I can configure everything in the GNOME GUI already, which makes YaST redundant. In Fedora I only remove 4 packages, but I see why Fedora installed it by default. Tumbleweed installs things that modern GNOME apps can already do, but doesn’t include them. It also installs the GNOME games, why? It would’ve been cool to have an option like ‘minimal install’ and just get the basics.

#2

Can’t edit my top post, so I’ll add some remarks here. Rolling back to the first install snapshot retains your home directory. So at least that! But I guess if you do a cleanup of your snapshots you might lose that first boot snapshot. And I suppose over time the initial package selection of Aeon changes as well. So after 2 years or so you might still be out of sync compared to a clean install. It’s not the end of the world, but that reset option in Silverblue seems very nice and I’m trying to find something like that for SUSE.

distrobox is by the way much better than toolbox, the latter is the default in Fedora Silverblue. Of course you can install that in Silverblue as well, but it’s not installed/recommended by default.

#3

I’m pretty new to this but what you said about Tumbleweed resonates with me.
I have tried at least 10 times to get a leap install without bloat and couldn’t get it to work(other distros were even worse).

I kinda gave up but than I found a video on microOS and it works like a charm. I have yet to use any rollback functions and I probably won’t need to much as I use the system for very basic things.

Interesting question about the difference in firewalls setup, thank you for giving me something to look into.

1 Like
#4

Welcome to openSUSE forums!

  1. There is/was an initiative to provide a reset to defaults (mod-check) but development seems to have stalled 'openSUSE Release Engineering meeting 08.02.2023' - MARC

  2. Firewalld last time I checked couldn’t close ports opened by rootful docker and docker compose. One would need to expose ports at the required interfaces from docker side, rendering firewalld a bit not helpful for this purpose. I don’t see bad interaction between firewalld and podman rootless. You can install it if you want particularly if you want to leverage zones.

  3. Contrary to MicroOS, Tumbleweed under default settings install recommended packages, so more packages packages than strictly necessary are installed. A slimmer package selection starts with turning off recommended packages. I have never installed TW this way so I have no idea how much work it takes to get a working install, but installing as few patterns as possible then switching off recommends after the install is a possibility.

1 Like
#5

Thank you for the welcome!

I was confused, I meant leap instead of tw.
Yeah turning off recommended packages helped a bit, but I still felt overwhelmed.
But maybe now because I’m a bit more proficient that wouldn’t be the case anymore.
However it was way easier to debloat manually than I tried with Manjaro, I got sorta stuck in a seemingly unending loop of dependencies trying to delete programs. Some really weird ones as well.

1 Like
#6

There is no “reset” option currently in Aeon, partially because you shouldn’t be installing much, if anything into the base system, and partially because of the way transactional-update and btrfs interact in order to make things work. It’s something that is being poked at when people have time, to create a similar functionality, but it’s not on the roadmap as a “must have”

No, it does not, and there are no plans to add or enable such. It isn’t required.

#7

But there are cases you have to. Such as getting libraries for a Yubikey to have MFA in GNOME and other hardware reasons. But if that hardware changes it would be great to reset the overlay to the intended first class package selection. At least, it’s quite useful in Fedora Silverblue. It gives you a proper way to “reinstall” your system without actually reinstalling. The mod-check option would be really cool to have.

A firewall is not required? Can you elaborate on that? Because I’ll install this on my laptop, and I will connect to semi-trusted networks. A firewall is required, also for devices in a fixed network. Defense in depth is not part of SUSE’s design?

1 Like
#8

[quote=“UPPERKEES, post:7, topic:167663, full:true”]

Hardware drivers indeed need to be installed in the system base, there’s no way around that. Aeon is based on MicroOS, which in turn pulls from the Tumbleweed sources. What “First Class package selection” are you talking about? It’s a rolling base, and things are getting updated as they get accepted into Tumbleweed. There’s no “rebase to a new release” like Silverblue.

What services are you running in the System Base that you feel a firewall would provide protection for? Because there aren’t any there, other than sshd by default.

#9

And I still restrict access to it to my home network only and I am not alone.

2 Likes
#10

And? I don’t understand what that means.

All the devices on your home network are wide open with publicly addressable IP addresses and running their own individual firewalls per device for access control?

Sure, maybe some folks have setups like that. I don’t know any. I don’t actually use Aeon, but Kalpa (fundamentally the same under the hood) and it’s rarely, if ever, directly connected to a publicly addressable IP address.

sshd is the only service in the base system that is enabled, and it’s restricted to key-based authentication, it’s not an issue, take it coffee shops, airports, hotels, whatever, exactly what would a firewall be protecting me from?

#11

Yes, all the devices that support IPv6 have publicly addressable IPv6 addresses.

#12

Ok, so Add the hosts/subnet/whatever that you want to have access to /etc/ssh/sshd_config.d/some_name.conf

This doesn’t require a completely seperate firewall, especially if sshd is the only service running on the host. Access Control for everything else is handled through your container setups.

#13

I have to ask, do you work at SUSE? Or do you have some kind of unique position in the community? Because I have a hard time accepting you are part of the SUSE team.

Have you heared of the OSI model and defense in depth? If your data on your laptop is valuable to you, then you have a firewall, especially if by default SSH is running. Compare that to Fedora Silverblue. 1) There is a firewall and 2) SSH is disabled by default. Protecting just the application layer is not really a strong defense.

There are by the way more processes running than just SSH. Some of it is running as localhost, but not everything. Avahi has had some security issues in the past.

Netid     State      Recv-Q     Send-Q                    Local Address:Port             Peer Address:Port     Process                                        
icmp6     UNCONN     0          0                                     *:58                          *:*         users:(("NetworkManager",pid=826,fd=27))      
udp       UNCONN     0          0                               0.0.0.0:5353                  0.0.0.0:*         users:(("avahi-daemon",pid=697,fd=11))        
udp       UNCONN     0          0                               0.0.0.0:50792                 0.0.0.0:*         users:(("avahi-daemon",pid=697,fd=13))        
udp       ESTAB      0          0                192.168.122.123%enp1s0:68              192.168.122.1:67        users:(("NetworkManager",pid=826,fd=25))      
udp       UNCONN     0          0                             127.0.0.1:323                   0.0.0.0:*         users:(("chronyd",pid=885,fd=5))              
udp       UNCONN     0          0                                  [::]:5353                     [::]:*         users:(("avahi-daemon",pid=697,fd=12))        
udp       UNCONN     0          0                                  [::]:55138                    [::]:*         users:(("avahi-daemon",pid=697,fd=14))        
udp       UNCONN     0          0                                 [::1]:323                      [::]:*         users:(("chronyd",pid=885,fd=6))              
tcp       LISTEN     0          128                           127.0.0.1:631                   0.0.0.0:*         users:(("cupsd",pid=853,fd=7))                
tcp       LISTEN     0          128                             0.0.0.0:22                    0.0.0.0:*         users:(("sshd",pid=879,fd=3))                 
tcp       ESTAB      0          0                       192.168.122.123:57244           151.101.37.91:443       users:(("gnome-software",pid=2045,fd=43))     
tcp       LISTEN     0          128                               [::1]:631                      [::]:*         users:(("cupsd",pid=853,fd=6))                
tcp       LISTEN     0          128                                [::]:22                       [::]:*         users:(("sshd",pid=879,fd=4))

And then the fact that firewalls also protect you against faulty network traffic, such as invalid connections, rate limiting, RFC1918 filtering, IDS/IPS and prevent any mistakes when something does listen on a public IP, like e.g. a container. I started a container and could connect to the port with netcat from another machine. There is no layer of protection. Containers often have weak security defaults/passwords. Again, defense in depth is something you expect by default nowadays. Of course someone can create a more secure container setup. But the point is that a firewall usually is protecting you against these kind of things. Windows also has this (for the past decades?).

The logic of not having a firewall would be equivalent to not having file permissions, encryption and SELinux. Because I’m the only user on the laptop and I have the password, so why would I need all that? that’s not the type of thinking you’d expect from a company like SUSE, at least I hope so?

No it’s not. I just connected based on password authentication.

The mod-check feature discussed by the SUSE project.

1. mod-check

     Working on a "mod-check" tool to report the following to users

     List of installed (1st party) packages, with comparisions to both an 
upstream pristine list and previous snapshots

     Automatically reset official packages to that upstream pristine 
list, or previous snapshots

     Any 3rd party packages and their origin

     Any known unsupported configurations/alterations and offer remedies 
if possible
#14

Again, you keep bringing SUSE up. SUSE has nothing to do with this. Zero, zilch, nada.

SUSE != openSUSE

I am not, nor have I ever been a SUSE Employee. Nor is SUSE consulted in any fashion, as to the design decisions made for Aeon and Kalpa.

There is no corporate decision being made here or anywhere else in openSUSE, outside of legal compliance issues, no matter how much you want it to be. Stop it.

I wasn’t clear here, you got me. I was speaking about my ssh setup, which has been changed from the default of password authentication (which is just standard practice for all my machines). You are correct, out of the box, when installed, password authentication is the default.

I am not a Network Engineer, nor a security professional. This decision was made by other members of the community development team, whom I trust, as they are more knowledgeable than I am.

I cannot give you detailed technical justifications as to why there is no firewall, beyond the explanations I was given by those other team members. You could very well be somebody that knows this stuff better than I do. I suspect you are.

I am just here relaying things as I understand them, as one of the developers of the project. We have a mailing list, and a matrix discussion channel MicroOS Mailing List, and a matrix discussion channel #aeon:opensuse.org, that is bridged to both Discord and Telegram (if those are your preferences) if you want to discuss it with them.

Nothing was discussed by the SUSE project. There is no SUSE project. We have only so many developers working on Aeon and Kalpa, and all of us are volunteers that are doing this, because it is a system we want to use. And this is not high on the list of priorities for any of the folks that are currently actively developing the MicroOS Desktop Variants.

#15

Thanks for the reply! Maybe Aeon and OpenSUSE in general is not for me then. Maybe in the future though, but with these design decisions I think it’s better for me to stick with Fedora for now. I wanted to switch, but Fedora allows me to just focus on my work and not with the distro I’m running on my laptop. I came from Debian and switching to Fedora gave me a lot of time to just focus on getting stuff done.

1 Like
#16

I agree; this thread is alarming.

2 Likes
#17

And that’s perfectly fair. MicroOS and by extension Aeon and Kalpa are not meant to be one-size-fits-all all-purpose distributions. If what the Fedora guys have going on with Silverblue works better for what you want to do, by all means, use it. It’s a good distribution. Choice is a good thing.

#18

If someone disables the firewall on a production machine, he/she is fired. If my mom disables her firewall on her PC, I would lecture her. If a distribution openly says there is no firewall needed without backing it up, then something is wrong. Choice is good, but these are clearly bad choices. If Silverblue can provide a firewalld setup at first boot in a distribution where containers are meant to be run, then OpenSUSE can/should too.

I know what you mean by the way with choice, but this is really not okay. Also the toolbox/distrobox container decision to not include the documentation without an easy way to get them back is hard to understand. If experienced users are confused by this because these choices result in a insecure and harder to use system, then who is the target audience exactly? You’re also not targeting newbies. I hope things will improve, because I was looking forward using a European based distribution with solid open-source values. But I guess I’ll be stuck with Red Hat/Fedora for a while (and that’s fine).

1 Like
#19

I don’t think there is such a thing. However there should be enough customisability that you can bash it into shape to fit any usecase. The issue with the firewall primarily is that this is one of the few things you can’t just add on yourself. I have this exact issue with the Steam Deck. If I want to decide to, for example, open or close ports related to KDE Connect on a public wifi, I just can’t. It’s always open. The last time I played around with the firewall it was so I could manage Radicale to use my desktop as a calendar server (by default the firewall blocks this). Would I even be able to do this on MicroOS?

A lot of Linux devs are obsessed with immutable filesystems because they make corporate life easier, but you’re so holden to the choices of the distro maintainers in cases like this that I’m worried about the direction, not just or necessarily openSUSE is going, but Linux as a concept.

For now there’s no plan on Tumblweed going anywhere, but I worry for the day this changes.

1 Like
#20

MicroOS does not have a desktop. And Aeon (RC) and Kalpa(alpha), well, they’re not ready for production.
It’s a change. We’ve done more changes: systemd, Tumbleweed, /usr/etc move, and there always were opinions, mostly of people not involved in the Project. Nobody is held by the maintainers choices. Everybody is free to contribute. Full stop here.