I think Firewalld is needed in Aeon / Kalpa

@StormCrow629 Hi, the filesystem is read-only and no services running, selinux lurking, so what would the firewall be doing? If you create a user distrobox instance eg Leap 15.5, then that should have it running if that instance is serving something up to the internet, but it’s an end user setup, so not sure why you would be running anything like that on Aeon anyway… MicroOS sure for running those types of applications.

There are lenghty discussions about this topic…

If you feel so passionately about there being a Firewall installed and enabled by default on Aeon and Kalpa, and believe you know better than the developers, we are always open to submissions. Set it up, make it work, We will look and see if we agree.

As one of the developers, I disagree that a firewall is “required” and just adds another layer of unnecessary complication, requiring more “support” effort from an already small team, for basically no real benefit to end users.

That’s where things live. You can submit changes or enhancements that you think would benefit the projects. And be the one to take responsibility for maintaining that functionality.

3 Likes

I can try that. Would you be able to advise what the minimum requirements and the ideal requirements that would be considered to include a firewall?

To be clear, I do not what to come off as knowing better that you and the rest of the development team. I am not privy to the context you all made your decision by. And I haven’t put in the work you all have.

Yah, I read that thread. I really hope I do not come across as that guy did. I haven’t contributed to openSUSE, and I really do respect the hard work that other put into to such a project. It isn’t easy to pull off any of these projects.

Edit: sorry for the deleted post. Never used this forum before and thought I responded to the wrong post.

If there were a firewall enabled, it would need to be adaptable to containerized services, with minimal, or no interaction from the user.

If a user spins up a distrobox, or uses podman to start a container, they shouldn’t have to be messing around with firewall rules, to make sure that container has the appropriate network access.

The containers themselves are already defining what network access they need, through podman networking, and the system isn’t intended for server use, the only default “service” running on Aeon and Kalpa is sshd, which requires authentication to connect to in the first place.

This is why we’ve decided that there is little, to no benefit for having a firewall installed. When you’re running containerized things, especially on a system that isn’t intended to have other people connected to it, it’s just redundant, you craft your containers to only have the network access they require, and nothing more. A Firewall would just add another layer of complexity to deal with that.

If you are attempting to host services that others are going to connect to regularly, That’s not the developed usecase for Aeon and Kalpa.

2 Likes

The use case with Fedora Silverblue is the same, right? Can’t that setup be copied? And if people run into issues, people themselves can disable the firewall. This could be a documented step on the wiki, just as there are some tips and tricks about SELinux.

I re-read the thread, I don’t see that I come off as rude. I just point at technical problems and I didn’t read any technical reasons why there couldn’t be a firewall by default, especially if Silverblue does offer it. Maybe it’s a cultural thing, in the Netherlands we usually don’t sugarcoat things and just talk straight to the point. :slight_smile:

1 Like

@UPPERKEES - Your point about maybe being a cultural thing could be relevant. A friend of mine from Iceland, explained to me how he had to change the way he interacts in the US, because of the difference in how English is organized, to be more polite. Where as Icelandic is more specific in terms and less generally vague than English. I don’t know any Icelandic though, so I can’t speak to that. (no pun intended)

Hope you are not offended by my comment. The perspective I was referring to is that while an argument for including a firewall was being made, there was not an offer to contribute to the solution.

An old manager of mine told me once if you are going to complain about something offer a solution, and be willing to help. Else the intend of the complain is often ignored.

There is also a lot of context missing in forums. Body language and what not. Also if I was on the dev team, and someone was questioning me and my peers work, I would genuinely be offended, if the comment I made came across as I no better. When they have put in the hard work, and I haven’t. It’s all about tone.

1 Like

It is indeed always a good practice to not just complain but also offer a solution. But to me it’s still unclear why Silverblue can provide this basic network security functionality with firewalld while Aeon hits a wall. If that is more clear, then who knows, maybe I can help out.

1 Like

@UPPERKEES - The issue is that firewall rules, and container networking rules can conflict with one and other if they do not have the same settings. I get where the developers are coming from. They want a desktop that is an easy platform for an application based desktop. And it does make complete sense.

Where I think a firewall is needed is to ensure containers are well encapsulated. SELinux, combined with a firewall in my limited opinion are a minimum requirement. Only, and I do mean only for the sake of security. Rooted / privileged containers can under certain circumstances be used to circumvent SELinux, while network rules can allow the host to be interacted with outside of the intended purpose of the app. That way the if at least the firewall is logging the network traffic even if permissive, there is a record if something goes wrong.

Now I want to be clear, the last thing I want to be doing is second guessing the decision of the development team. They do solid work. I’m just think about how would I go about compromising the machine. Also Docker - Docker security | Docker Docs, specifically calls out that a firewall and other resources should be used for network management not the container, unless the container is being used as a firewall, or router, etc.

The Firewalld team, has considered here - Policy Objects: Filtering Container and Virtual Machine Traffic | firewalld, how to use the firewall to manage container port forwarding, masquerading, and filter communication to the host. The ‘conclusion’ of the page even says the Firewalld team, want to work with teams to facilitate container needs.

But, and this is important, whom is going to put in the effort to coordinate and mange that aspect f the project? So I do not want to fault or criticize the dev team. They have a specific design purpose for Aeon / Kalpa, which what I have just refereed to may not be pertinent. Which is for them to decide. Not us.

If you want to help, make a virtual machine of either Aeon or Kalpa, and enable ‘firewalld’, it can be installed from Yast during installation. Then do a transactional install of ‘firewall-config’ to get the graphical front end for Firewalld. Then setup the firewall to handle the container nedworking needs. Just think what a general desktop workstation applications would need. Doesn’t need to be anything more than a proof of concept.

The setup just needs to demonstrate the feasibility, and identify the needed resources to justify why Firewalld is needed. After that we can let the design team decide if that fits the projects needs.

Thoughts?

1 Like

@StormCrow629 @UPPERKEES Hi, Aeon and Kapla are focused on the end user experience, there are better openSUSE options if wanting to run services, Leap, Tumbleweed and MicroOS.

@malcolmlewis - Hello. Yah, I’m not thinking of using either Aeon or Kalpa for hosting services. But I am thinking about its security as a desktop. Specifically I’m reminded about XP not having a firewall or antivirus, mid 2000s. That was a hard hit for MS and its market share. I also am thinking about company info sec rules, which may have a specific requirement that a platform they use has specific criteria, like a firewall.

Aeon and Kalpa are not meant to run on end users/employee machines connected to the open web…
The use case is different to the machines that are handed out to every employee for “normal” job tasks.

1 Like

What?

Aeon and Kalpa are absolutely intended for End Users. What use is a desktop focused operating system to anybody other than end users?

2 Likes

Excellent overview and thanks for putting that much time and thought in it. But the ‘but’ for me is still why Silverblue does provide a firewall and has the same kind of use case. I agree that a MicroOS system with e.g. k3s shouldn’t use a firewall. Because that’s clearly described in the k3s docs. But a regular desktop is used very different, the attack vectors are broader.

Having the same kind of firewall setup as Silverblue may boost the security in-depth approach on Aeon and alike. And if developers run into a wall, then sure, systemctl disable --now firewalld if that’s the most practical way of dealing with it. That step could be on the Aeon wiki with an explanation. In that case network security is covered by default. I for example don’t run into any issues on my current Fedora workstation using Flatpak and containers. That said, I don’t run k8s stuff or containerized web services on my workstation either. For that I have dedicated servers, also at home.

We are not the Fedora Project.

If your only justification for including something is “Because Fedora Does it” then it’s meaningless.

This is the default firewall configuration for Fedora Silverblue, since you keep bringing it up.

sfalken@fedora:~$ firewall-cmd --list-all
FedoraWorkstation (default, active)
  target: default
  ingress-priority: 0
  egress-priority: 0
  icmp-block-inversion: no
  interfaces: enp1s0
  sources:
  services: dhcpv6-client samba-client ssh
  ports: 1025-65535/udp 1025-65535/tcp
  protocols:
  forward: yes
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules: 

ALL ports above 1024 are open by default, And the ports for dhcpv6-client, samba-client, and ssh are open in the firewall.

So what exactly is the firewall on fedora protecting you from? The reason it works with podman/toolbox on Silverblue is because it isn’t doing anything, that’s how they get around it. Sure, it’s blocking all ports under 1024, but if you’re not running any services on the machine, again, what is it protecting you from?

I’m starting get really tired of this. We are not Fedora, We are not Silverblue. Just because Fedora does something, doesn’t mean we have to, or should. Just because some “security expert” out there on the web says that something is a must doesn’t make it true.

Can a firewall be part of an overall security strategy? Absolutely. Is it required at all times? Absolutely not.

The default configuration of Aeon and Kalpa has exactly one service enabled, sshd. And as stated previously, that requires authentication to connect to in the first place. How would including a firewall to block ports that no services are running on in the first place, improve security?

There is no but. If this makes Aeon and Kalpa unsuitable for corporate environments, so be it. I’m now signing off on this thread, because I’m honestly getting tired of having this same debate, over and over again.

I have zero interest in putting in the work myself to enable a firewall on Kalpa, as I’m quite pleased with our security setup the way it is. I’ll let Richard and his team speak for themselves when it comes to Aeon. When somebody who wants to put in the work to create a firewall implementation that works well with the containerized nature of the workloads on MicroOS based systems gets something put together, I’ll have a look, and consider it.

6 Likes

Further to @sfalken comments, I also disable keyboard interaction with ssh so it’s keys only. With just that service, I can manage my systems, connect filesystems with sshfs, backup systems with rsync etc…

2 Likes

@sfalken - Hello. I’m not really certain what was said that was so upsetting. But my apologies that you found it upsetting. openSUSE is not Fedora, and I don’t think an argument is being made that it should have a feature like a firewall because Fedora does. Instead the argument I am making that one should be included is so that it can be used to configure network services for containers running on the host. Which is feasible per Firewalld documentation, and recommended per Docker, which Distrobox supports.

The only ask so far, has been to identify what requirements would need to be meet in order to justify including one. Which you provided. With recognition that the decision would rest with the development teams managing the project. I thought I made it clear that I was interested in doing the research, and see if the worked was justifiable. I am also potentially interested in putting the the needed work to implement, if I have the skill set for it.

I’m not certain what other debates you have had. Other than what I read before posting this here in the SoapBox area. You last post reads to me like you are holding those past conversations as a part of this conversion.

So I am just going to ask. If Firewalld can be included in Aeon / Kalpa per the requirements initially defined earlier in the thread. Would you and the development team be interesting in seeing if that feasability would be justified to add? At which point if there is a scope f work that needs to be defined, it can be defined then, as that potential work is not relevant now.

If so great! And if not that too is fine, and I will drop this topic.

Your thoughts?

1 Like

This, right here, explains very clearly and succinctly why a firewall is of no use in Aeon or Kalpa.

It does nothing on Silverblue that isn’t already done by other mechanisms in place.

This discussion has been had, the idea has been declined by the developers and their reasons have been explained, both here and on Reddit.

As was discussed in the other threads, for those who really feel it’s necessary, you can add it and manage it yourself.

This discussion is now closed.