Description of problem: The default stateful iptables rules created by s-c-securitylevel are not sufficient to allow network clients based upon broadcast or multicast protocols to work, such as smb:/// browsing in Nautilus. As a result, the user has a bad experience with a secure system. The best fix for this is to enhance the kernel netfilter/iptables conntrack module to match state on broadcast/multicast-based protocols, to be able to allow the reply to a broadcast/multicast query back in. I am filing this bug on s-c-securitylevel in the mean time in hopes of a suitable workaround that may be used until then. The URL of this bug points to a possible workaround using -m recent. While it is probably not possible to make a workaround for every protocol, it is important to at least fix the SMB case for now, since it is such a user-visible feature which is expected to just work. Version-Release number of selected component (if applicable): 1.3.1-1 How reproducible: Steps to Reproduce: 1. start system-config-securitylevel 2. Enable Firewall 3. open Network Servers or type smb:/// ito Nautilus location bar Actual results: Browsing for SMB servers breaks. An SMB query is sent to the subnet broadcast address, replie(s) come back, but they are dropped by iptables. iptables sends an ICMP error message back to the server(s) that replied. Expected results: Client protocols, such as SMB browsing, should continue to work on a secure system with the firewall enabled. Additional info: See also discussion on fedora-devel-list: http://www.redhat.com/archives/fedora-devel-list/2004-January/msg01012.html
notting: Any opinions here?
It would be nice to fix the kernel in such a way - it would fix printer browsing too.
Changing component to the kernel.
What would be involved in changing the kernel to support this ? Is it a config option, a patch from netfilter patch-o-matic, or as of yet non-existing code ?
I wrote a conntrack module for this: http://www.redhat.com/archives/fedora-devel-list/2004-September/msg01178.html
I added ip_conntrack_netbios_ns.c to kernel-2.6.8-1.541, edited /etc/sysconfig/iptables-config to add IPTABLES_MODULES="ip_conntrack_netbios_ns" and it appears to work fine.
This is also bug 133478
Dave: What has to be done to get this moved forward? Is this assigned to the wrong module?
still no sign of anything in the upstream kernel. Keep prodding the netfilter guys until they take it. If they won't take it, I'd like to know why. If theres something fundamentally wrong with it, then its obviously not good enough for the Fedora kernel either.
*** Bug 133478 has been marked as a duplicate of this bug. ***
The patch and some discussion about it is here: https://lists.netfilter.org/pipermail/netfilter-devel/2004-October/017159.html Some people claimed i needed to re-issue the expectation as soon as it is confirmed by the first packet, but whenever I tested that all I got was kernel panics, so I was unable to make any progress. I sort of hoped that someone who has more clue about netfilter than I would take a serious look at this, as they could probably get this fixed in an hour or so. This is an extremely embarrasing bug that we've had a big fat "warning you need to disable the firewall to make the desktop work" item in our release notes for the last three releases due to this.
jmorris: What would it take to get you to take a serious look at this? It should be really easy for you, and fixing this bug would be very very nice for the desktop.
Someone added ip_conntrack_netbios_ns.ko to 2.6.14, and it is now built in Rawhide. All we need to do now is to make sure we load this module when the firewall is enabled.
Remember to get rid of: http://fedoraproject.org/wiki/Docs/Beats/Samba when this is fixed.
Please try tomorrow's system-config-securitylevel package and let me know how it works. Clicking on the Samba box should cause the ip_conntrack_netbios_ns module to be loaded. I may still need to go in and remove previous code that opens a variety of Samba-related ports for running a service. Thoughts on this?
clumens: No no no. That is wrong. The ip_conntrack_netbios_ns should always be loaded (at least by default, but its highly unlikely you'd want to disable it unless you're doing a totally custom firewall). It really has no security disadvantages, since it only affects replies to broadcasts sent from your computer. The samba checkbox is for something completely different, namely if you are running a samba server. If you really wanted a checkbox for this it would be called something like "Working windows share integration in the desktop".
If it should always be loaded, that seems like a bug in iptables (the package that provides /etc/sysconfig/iptables-config) or possibly in whichever package would provide a program for browsing Samba shares.
I'm not sure what you mean? Should nautilus and konqueror load kernel modules? That makes no sense at all (and is not possible, as it requires root access). I guess it could be done in the iptables package, but I think it makes more sense to have it in the package that sets up the default firewall. Without s-c-sl there would be no firewall set up, right? And in that case you wouldn't need to load the module. If you manually set up the firewall you might not want the module (for some strange reason), but if you just enable the default firewall it is guaranteed that you want this module. (If you don't use a smb browser it won't affect security, but if you do it actually works.)
Okay, new version to try out.
clumens: I tested todays rawhide (s-c-s 1.6.9-1) and it seems to work. I.E. after boot "smbtree -DN" shows me the workgroup i've set up on another samba machine on the network. When I remove the module line in /etc/sysconfig/iptables-config and reboot the workgroup doesn't show up. Turning on debugging (-d 10) in smbtree shows clearly that the problem is that the broadcast doesn't get a response, and loading the module makes it work. So, the firewall problem has been fixed! YAY! However, something else seems to have broken the smb support in Gnome, so clicking on the "windows network" icon doesn't work. *sigh*
Excellent news! Alex, the GNOME bug you refer to is bug #168908 ? I'd like to track it. Many thanks!
No, that one is different. I can display smb:/// , I just don't get any workspaces in it. smb://host/ works fine though. I haven't actually filed a bug about it, just made a note here to figure out what it is (might be some local problem).