Bug 57241 - /etc/rc.d/init.d/ipchains has incorrect functionality
Summary: /etc/rc.d/init.d/ipchains has incorrect functionality
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: ipchains (Show other bugs)
(Show other bugs)
Version: 7.2
Hardware: All Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact:
Keywords: Security
Depends On:
TreeView+ depends on / blocked
Reported: 2001-12-07 18:36 UTC by Steven W. Orr
Modified: 2008-08-01 16:22 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-12-07 19:46:29 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Steven W. Orr 2001-12-07 18:36:25 UTC
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:

Steps to Reproduce:

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:

Comment 1 D. Stimits 2001-12-07 19:46:24 UTC
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

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.

Comment 2 Mike A. Harris 2001-12-07 19:49:14 UTC
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.

Comment 3 Mike A. Harris 2001-12-07 19:55:22 UTC
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

Comment 4 D. Stimits 2001-12-07 20:32:18 UTC
I once did file for it. The reply was:

--- 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   
+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@redhat.com 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

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.

Note You need to log in before you can comment on or make changes to this bug.