|Summary:||default iptables firewall rules don't allow Network Servers smb:/// browsing|
|Product:||[Fedora] Fedora||Reporter:||Charles R. Anderson <cra>|
|Component:||system-config-securitylevel||Assignee:||Chris Lumens <clumens>|
|Status:||CLOSED RAWHIDE||QA Contact:|
|Version:||rawhide||CC:||alexl, davej, dgunchev, gajownik, marius.andreiana, markmc, notting, riel|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-11-15 08:48:26 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
Description Charles R. Anderson 2004-01-20 04:24:15 UTC
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
Comment 1 Brent Fox 2004-03-05 15:31:16 UTC
notting: Any opinions here?
Comment 2 Bill Nottingham 2004-03-05 15:51:39 UTC
It would be nice to fix the kernel in such a way - it would fix printer browsing too.
Comment 3 Brent Fox 2004-03-05 16:13:21 UTC
Changing component to the kernel.
Comment 4 Rik van Riel 2004-09-29 12:43:22 UTC
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 ?
Comment 5 Alexander Larsson 2004-09-29 12:49:36 UTC
I wrote a conntrack module for this: http://www.redhat.com/archives/fedora-devel-list/2004-September/msg01178.html
Comment 6 Charles R. Anderson 2004-10-04 06:47:46 UTC
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.
Comment 8 Bryan W Clark 2005-01-24 17:32:08 UTC
Dave: What has to be done to get this moved forward? Is this assigned to the wrong module?
Comment 9 Dave Jones 2005-01-24 23:28:28 UTC
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.
Comment 10 Marius Andreiana 2005-08-23 14:18:11 UTC
*** Bug 133478 has been marked as a duplicate of this bug. ***
Comment 11 Alexander Larsson 2005-09-02 09:51:49 UTC
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.
Comment 12 Alexander Larsson 2005-09-02 10:01:23 UTC
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.
Comment 13 Alexander Larsson 2005-10-31 14:51:56 UTC
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.
Comment 14 Alexander Larsson 2005-10-31 15:05:32 UTC
Remember to get rid of: http://fedoraproject.org/wiki/Docs/Beats/Samba when this is fixed.
Comment 15 Chris Lumens 2005-11-01 15:56:31 UTC
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?
Comment 16 Alexander Larsson 2005-11-03 10:05:27 UTC
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".
Comment 17 Chris Lumens 2005-11-03 14:43:05 UTC
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.
Comment 18 Alexander Larsson 2005-11-04 09:53:49 UTC
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.)
Comment 19 Chris Lumens 2005-11-04 19:40:50 UTC
Okay, new version to try out.
Comment 20 Alexander Larsson 2005-11-15 08:48:26 UTC
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*
Comment 21 Marius Andreiana 2005-11-15 12:45:04 UTC
Excellent news! Alex, the GNOME bug you refer to is bug #168908 ? I'd like to track it. Many thanks!
Comment 22 Alexander Larsson 2005-11-18 07:40:19 UTC
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).