Red Hat Bugzilla – Bug 446828
Firewall should not block Multicast DNS and CUPS by default
Last modified: 2010-05-04 03:02:50 EDT
Description of problem: Currently the default firewall rules prevent Multicast DNS (and thus service discovery via Avahi) and CUPS browsing from working. This ruins the "just works" feeling. Aunt Tilda wants to share files. She enables file sharing under Gnome. Uncle Eddie looks on the network but cannot see the file share, the new firewall rules prevent that from happening. He is likely to just shut if off rather than bothering with enabling the required services (and Multicast DNS is really not obvious for this). If course there still is the problem that the port used by apache for opening webdav is not open by default, that's another thing that hasn't been fixed an awful long time. But still multicast DNS is used for a lot more these days: music sharing, easy access via VNC, SSH file access etc.), plain simple host name lookups... For CUPS it makes it pretty inconvenient now that printers do not just appear but you first have to tweak your firewall or add it manually again (what a giant leap backwards). For example guests at our university can no longer just use the printers, they have to go and configure them. Version-Release number of selected component (if applicable): system-config-firewall-1.2.7-1.fc9.noarch Proposal: Open UDP/5353 and UDP/631 again for seemless "just works" networking experience.
I am sorry, but this is not a good example, because "Aunt Tilda" might not want to share with the whole world. Also sharing a printer over a ppp or isdn line might not be a good idea in general. What if you want to share it in the intranet only and not anyone else in the world? Opening ports or services per default is a security risk.
Multicast DNS does not use any point-to-point connections by design unless explicitly enabled in the config file, so PPP/ISDN/DSL/whatever connections are not a problem. Also it is only enabled for link-local peers. I can understand that for example in a cafe with a wifi hotspot you'd like this disabled. Maybe this should be integrated with NetworkManager in that case to allow disabling certain services for connections. This pretty quickly comes down to a FirewallKit... Not providing a sensible and easy way (and s-c-f does not count as such) it just gives a very bad experience. Especially since the requested ports are only relevant on the local network they do not pose the classical "attack over the internet" risk. SSH is open by default, based on the recent events this is much more dangerous than multicast service discover/name lookup and announcing printers I'd say. Besides that I didn't see any related issues in Avahi, I think it has a pretty good track record. I'm also not aware of a problem in CUPS that was related to the browsing functionality. I'm not saying because there has been no problem there will be no problem, but using these services over the last past years has not been a problem.
The initial firewall configuration is done in anaconda, therefore this bug should be assigned to anaconda, it should enable the desktop defaults for the firewall.
Where are desktop defaults defined? Should we re-assign to anaconda then? Especially if this is meant to be the desktop firewall I'd say to enable these ports to make networking just work. An option to set a fixed port for file sharing would be cool though to be able to allow this to work with the standard firewall as well.
anaconda is using lokkit for the initial firewall configuration anyway to open the ssh port. It simply can use "lokkit --default=desktop" for a desktop and "lokkit --default=server" for a server machine.
*** This bug has been marked as a duplicate of 442345 ***