The printer-firewall nonsense must be fixed. It's a major security issue

In my opinion, requiring the user to deactivate the firewall to add a wireless printer is very poor in terms of security. It seems it’s the only way to connect a printer (setting the zone to “internal” wasn’t enough for me.). I’m no security expert, but a firewall allowing printers seems more secure to me than no firewall at all.

It’s especially strange considering no other distro does that. I love Tumbleweed but this issue, in addition to being super infuriating, seems really easy to fix. I don’t know how this hasn’t been adressed yet.

2 Likes

It doesn’t require that, (although it’s often easier for new Linux users to do so on a temporary basis). In general, opening the IPP and mDNS/SD ports is sufficient for dynamic network printer discovery.

3 Likes

Well that’s the thing, setting the zone to internal and adding both ipp and ipp-client to the list of open ports didn’t do it. I restarted the firewall twice, rebooted twice, still nothing. Deactivating the firewall was the only way.

The internal zone should have mdns enabled by default. Did you check that the network interface is assigned to that zone?

firewall-cmd --list-all-zones

Is the network printer found using these commands?

lpinfo -v
avahi-browse -at
2 Likes

Couldn’t agree more. I realize openSUSE has strong ties to the enterprise SUSE…but openSUSE is not an enterprise distro. Therefore, in areas like this, the defaults should be more sane for the desktop user openSUSE is aimed at.

Not being able to easily set up a printer is what drove Linus Torvalds to switch to Fedora. That says everything about whether this is a sane default for desktop users.

3 Likes

As this is not a request for technical assistance, it will be moved from Hardware to Open Chat.

Fedora uses firewalld, and the default firewall configuration is no different to openSUSE:

This is what I got:

lock
  target: %%REJECT%%
  ingress-priority: 0
  egress-priority: 0
  icmp-block-inversion: no
  interfaces: 
  sources: 
  services: 
  ports: 
  protocols: 
  forward: yes
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 

dmz
  target: default
  ingress-priority: 0
  egress-priority: 0
  icmp-block-inversion: no
  interfaces: 
  sources: 
  services: ssh
  ports: 
  protocols: 
  forward: yes
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 

docker
  target: ACCEPT
  ingress-priority: 0
  egress-priority: 0
  icmp-block-inversion: no
  interfaces: 
  sources: 
  services: 
  ports: 
  protocols: 
  forward: no
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 

drop
  target: DROP
  ingress-priority: 0
  egress-priority: 0
  icmp-block-inversion: no
  interfaces: 
  sources: 
  services: 
  ports: 
  protocols: 
  forward: yes
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 

external
  target: default
  ingress-priority: 0
  egress-priority: 0
  icmp-block-inversion: no
  interfaces: 
  sources: 
  services: ssh
  ports: 
  protocols: 
  forward: yes
  masquerade: yes
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 

home
  target: default
  ingress-priority: 0
  egress-priority: 0
  icmp-block-inversion: no
  interfaces: 
  sources: 
  services: dhcpv6-client mdns samba-client ssh
  ports: 
  protocols: 
  forward: yes
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 

internal (active)
  target: default
  ingress-priority: 0
  egress-priority: 0
  icmp-block-inversion: no
  interfaces: docker0
  sources: 
  services: dhcpv6-client ipp ipp-client mdns samba-client ssh
  ports: 
  protocols: 
  forward: yes
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 

nm-shared
  target: ACCEPT
  ingress-priority: 0
  egress-priority: 0
  icmp-block-inversion: no
  interfaces: 
  sources: 
  services: dhcp dns ssh
  ports: 
  protocols: icmp ipv6-icmp
  forward: no
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 
        rule priority="32767" reject

public (default, active)
  target: default
  ingress-priority: 0
  egress-priority: 0
  icmp-block-inversion: no
  interfaces: wlp4s0
  sources: 
  services: dhcpv6-client
  ports: 
  protocols: 
  forward: yes
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 

trusted
  target: ACCEPT
  ingress-priority: 0
  egress-priority: 0
  icmp-block-inversion: no
  interfaces: 
  sources: 
  services: 
  ports: 
  protocols: 
  forward: yes
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 

work
  target: default
  ingress-priority: 0
  egress-priority: 0
  icmp-block-inversion: no
  interfaces: 
  sources: 
  services: dhcpv6-client ssh
  ports: 
  protocols: 
  forward: yes
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 

Or, is it something else?

The Originator doesn’t mention which Desktop is being used …


Here with KDE Plasma and Leap 15.5 –

  • Printer configuration has plagued me for years – YaST was never really discovering network printers.

Then, due to another issue, I checked Zeroconf – the package “kdnssd” was missing –

This package adds Zeroconf support to KIO, allowing the use of this protocol in all applications that are using KIO.

I used to believer that, YaST was Desktop independent but, suddenly, after installing the support for network service discovery to KIO (KDE Input/Output), YaST suddenly “found” (discovered) the network printers – currently connected to the printer via “dnssd:” and a UUID

lpinfo -v” also now finds the “ipp:” services as well as the “socket:” services via the fixed IPv4 addresses assigned to the printers by the DHCP server …

The wireless network interface is not assigned to the internal zone (as I suspected). It is assigned to the public zone.

  target: default
  ingress-priority: 0
  egress-priority: 0
  icmp-block-inversion: no
  interfaces: wlp4s0
  sources: 
  services: dhcpv6-client
  ports: 
  protocols: 
  forward: yes
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 
1 Like

Oh my bad, how do you change that? I’ve tried through yast, here’s what the setting looks like:

Nvm I found it, I chose my wifi connection from KDE’s network menu, and from there I can choose a firewall interface. Okay so it’s much clearer now, but I maintain it does be convoluted just to add a printer.

1 Like

Not really. One (as the administrator of their system) just needs to be conscious of making sure that the firewall configuration is suitable fort heir needs. In this case the internal and home zones provide the necessary configuration for printer discovery via mDNS. Of course, the zones are just preset configurations that can be further configured as required for particular use cases.

The graphical firewall-config utility is superior to that provided by YaST if one must use a GUI.

Having used both openSUSE and Fedora extensively, there is a big difference. Fedora detects printers out-of-the-box, much like Ubuntu and Debian-based distros…openSUSE does not.

Fedora may use firewalld, but they have it pre-configured to allow printing, while openSUSE has it locked down and requires the user to set it up.

Mistakenly hit general reply, instead of replying to your post specifically. See my reply above regarding Fedora comparison.

You didn’t need to do that. As a watcher, I see the reply anyway.

Yes, perhaps openSUSE is stricter, but that reduces security risk, and as the administrator of the openSUSE distro it is expected that users can cope with reading documentation as required and adjusting firewalls to suit their own needs. Not hard to change the zone (even via Networkmanager when configuring the network).

I don’t disagree that it makes it more secure, that’s one of the things I like about openSUSE. Nonetheless, when Linus Torvalds can’t even get printers working, it can be argued that it’s not just a matter of “reading documentation as required.”

openSUSE is literally the only mainstream distro that cannot print OOTB, without mucking around with the firewall. At some point, it doesn’t matter what the rational is. When this keeps coming up over and over again, with many saying “just disable the firewall to print,” there’s an opportunity to do something better.

Perhaps a simple toggle on the welcome screen for newer users, a button that asks if they want printing enabled, that automatically sets the correct zone.

The problem here is not that OpenSuse defaults to the safer public zone and other distros do not. It’s expecting the end-user to know about firewalls and zones in the first place.
The documentation shows a deprecated GUI utility to switch firewall zones.

The simplest solution would be to ask the user when they’re connecting to a new network whether to trust it or not. For example, this is what Windows does. You can always go into the network properties and make it public/private after the fact too.

2 Likes

On that note, does anyone here using firewalld change their zones before connecting to a different network? What do you use to do that, a bash alias, some toggling widget that executes the firewall-cmd command?