From Bugzilla Helper: User-Agent: Mozilla/4.7 [en] (X11; I; SunOS 5.7 sun4u) Description of problem: ipchains is supposed to load a module. Instead its load is conditional on whether it finds a Red Hat supplied firewall to run in /etc/sysconfig/ipchains. ipchains is defined as a service and should run regardless of whether I want to use the supplied ipchains firewall instead of the firewall I am currently using. (In my case I'm running pmfirewall.) I don't mind that the service can fail to load and not report an error (e.g., if you want to run iptables instead), but it definitely should not fail to load the module just because the file /etc/sysconfig/ipchains doesn't have a valid firewall in it. It's incorrect to assume that everyone will want to run the firewall that Red Hat supplies (especially since pmfirewall is better :-) Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.reboot 2. 3. Actual Results: My firewall failed to execute because the ipchains module did not load. Expected Results: I should have had a running firewall. Additional info:
Redhat ipchains and iptables init scripts are all vulnerable to silent failure. Other distributions seem to have similar vulnerabilities as well. The 2.4.x kernels...ALL 2.4.x kernels...are incapable of loading both ipchains and iptables modules at the same time. There is no such thing as a Redhat kernel, or any kernel, that will allow ipchains modules to be loaded if iptables is supported via *either* loading iptables module *or* compiling in iptables support. The converse is also true, there is no such thing as a kernel that will allow iptables to be supported in any way whatsoever if an ipchains module is currently loaded or supported via compiled in functionality. ipchains and iptables are mutually exclusive, period, they *cannot* live together under any circumstances. The scripts are a security nightmare because they assume that if the kernel does not support ipchains or iptables, regardless of whether it really does not support the feature or if the feature is being pushed aside by a mutually exclusive load of a competing module, that the user should not have run the script in the first place, or else does not want to be told about non-existent features, and will not indicate failure in any way. The only time ipchains or iptables scripts will tell about failure is if the correct module or support is already working correctly. The scripts are an extreme danger to security, but could be fixed by allowing them to report failure regardless of whether it is a bad rule or whether the module is not loaded. It would be a really good idea if the ipchains script detected a loaded iptables module and replied [conflict]; if failure was not due to conflict but due to lacking kernel functionality, e.g., if the ipchains.o module got deleted, it would be nice for the failure to report [unsupported]. As is, both of these failures are being covered up. The iptables script could do the reverse, and report [conflict] if the ipchains.o module is loaded, or report [unsupported] if the iptables.o module simply can't be found. It is not practical to expect the kernel to support both modules under simultaneous load. This is security flaw in the scripts, not the kernel. Scripts should never hide failure of a security feature.
No, this is definitely not a bug. The purpose of the included ipchains initscript is solely for the use of the Red Hat ipchains firewall tools. It is not and never was intended to be used for a general mechanism for loading the ipchains module. There was a bug in Red Hat Linux 7.1 that allowed users to use the script for this purpose. That bug was fixed. The proper "Red Hat official defined way" of loading the ipchains module, or any other kernel modules that are not loaded automatically by kmod, is for the user to edit /etc/rc.d/rc.modules, creating that file if necessary, and put in the modprobe commands required to load the module or modules. Alternatively, a user can create their own script to do so, such as "/etc/init.d/pmfirewall" for example. The two initscripts ipchains and iptables are poorly named, no question. I don't know who named them that, or what they were thinking at that time. I would have called them something different myself. Nonetheless, in either case, this is not a bug.
stimits: Your comment above was not seen when I submitted mine (mid air collision). Your comment has some valid points to it, however it is completely an orthogonal issue to the reported bug. Feel free to file a request for enhancement for the desired functionality.
I once did file for it. The reply was: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=43708 --- shadow/43708 Sun Oct 7 08:22:37 2001 +++ shadow/43708.tmp.19063 Tue Oct 30 02:01:53 2001 @@ -3,8 +3,8 @@ Version: 7.1 Platform: i386 OS/Version: Linux -Status: ASSIGNED -Resolution: +Status: CLOSED +Resolution: NOTABUG Severity: security Priority: high Component: ipchains @@ -52,3 +52,14 @@ deactivated is "not good". There is an extreme need to test for ipchains failure to activate, whether it is by direct failure, or by kernel support failure. + +------- Additional comments from mharris 2001-10-30 02:16:34 ------- +This is not really a bug, because Red Hat Linux does not support +user compiled kernels. You're free to compile and use your own +kernel of course, but problems introduced by doing so, that are +not reproduceable with the supplied kernels, are not generally +considered bugs. + +If you can cause a reproduceable problem by using the Red Hat +supplied kernel, then it is something worthy of investigating +further. My request was called "NOT A BUG", and deemed to only be a problem on non-Redhat kernels. Somehow it got misdiagnosed as being a non-Redhat kernel problem, though it is clearly a script problem with all kernels.