Bug 138143

Summary: RFE: Avoid implicitly overwriting user customizations to the firewall (e.g. manual additions to /etc/sysconfig/iptables)
Product: [Fedora] Fedora Reporter: Daniel L. Rall <dlr>
Component: system-config-firewallAssignee: Thomas Woerner <twoerner>
Status: CLOSED RAWHIDE QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: rawhideCC: amessina, bfox, jshin, mattdm, nobody+pnasrat, zaiwen
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: [data loss can occur without this change]
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-05 12:15:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 175947    
Bug Blocks: 177950    
Attachments:
Description Flags
Sample iptables configuration file generated by system-config-securitylevel, then subsequently manually edited none

Description Daniel L. Rall 2004-11-04 22:30:46 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20040922

Description of problem:
system-config-securitylevel is quite a useful tool for getting started
with iptables.  Its GUI generates a clean, usable configuration file
which provides excellent insight into iptables's configuration syntax.
 However, it doesn't support the full range of functionality offered
by iptables (e.g. masquerading, IP blocking, etc.).  Today, to get the
additional functionality your average user needs for a small office or
home network, she will scour the web looking for the Right config
snippets, modify them to her environment, and paste'em into her config
file.  If system-config-securitylevel is later invoked again, those
necessary, hand-coded config snippets will be blown away.

The comment "Manual customization of this file is not recommended."
does indeed exist in the generated iptables configuration file,
hinting to users that an overwrite may occur.  However, overwriting is
simply not desirable behavior.

Version-Release number of selected component (if applicable):
system-config-securitylevel-1.3.12-1

How reproducible:
Always

Steps to Reproduce:
1. Run system-config-securitylevel and setup a firewall.
2. Add some additional lines to the /etc/sysconfig/iptables
configuration file generated by system-config-securitylevel.
3. Re-run system-config-securitylevel, making a minor change to the
firewall configuration setup in step #1.


Actual Results:  Configuration lines manually added in step #2 have
disappeared.  Any changes from step #3 exist as expected.

Expected Results:  Lines in the config file not matching those
generated by system-config-securitylevel should be preserved.  Since
the manual configuration has the possibly of interfering with the
tool-generated configuration, the tool's UI should indicate to the
users of that their file contains "unexpected" configuration.

Since this indication of manual customizations is useful regardless of
whether the contents of the file is modified or not (you do NOT want
to overwrite user customizations), I recommend a permanent flag in the
GUI (as opposed to a popup message), and possibly a no-op and warning
message from the text-based UI.


Additional info:
Other bug reports and enhancement requests noted that Firestarter
might be a useful tool to integrate to help with configuring the firewall.

Comment 1 Daniel L. Rall 2004-11-04 22:32:08 UTC
Created attachment 106196 [details]
Sample iptables configuration file generated by system-config-securitylevel, then subsequently manually edited

Comment 2 Paul Nasrat 2004-11-23 15:17:00 UTC
Currently this is how s-c-securitylevel works, it assumes that it's in
control

Future work will enable better customisation see bug #124161 for
example.  The correct fix here is to enable it so you can configure
what you need via gui/tui.

Comment 3 Daniel L. Rall 2004-11-23 17:47:51 UTC
That's not really a reason _why_.  And it sucks.

Comment 4 Daniel L. Rall 2004-11-23 23:39:35 UTC
In bug #124161, Paul suggested that I re-open this bug as an
enhancement.  Without this change, users lacking the non-obvious piece
of knowledge that "system-config-securitylevel assumes it's in
control" cannot make edits to /etc/sysconfig/iptables, nor use any
other related software which writes iptables' config file.

Comment 5 Matthew Miller 2005-04-26 15:20:04 UTC
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.

Comment 6 Chris Lumens 2005-11-29 19:59:54 UTC
*** Bug 171947 has been marked as a duplicate of this bug. ***

Comment 7 Chris Lumens 2005-11-29 20:01:14 UTC
*** Bug 173231 has been marked as a duplicate of this bug. ***

Comment 8 Anthony Messina 2006-01-17 10:38:19 UTC
(In reply to comment #5)
> Fedora Core 2 is now maintained by the Fedora Legacy project for
> security updates only. If this problem is a security issue, please
> reopen and reassign to the Fedora Legacy product. If it is not a
> security issue and hasn't been resolved in the current FC3 updates or
> in the FC4 test release, reopen and change the version to match.

The bugs that have been marked duplicates of this bug were opened against FC4,
so there should not be a need to reopen the bug in those versions as they are
already there.

What is the status on this bug?

Comment 9 Chris Lumens 2006-01-17 15:12:27 UTC
Waiting for some movement on bug 175947, which I made this one depend on a while
back.  Getting that one done will give me a quick and easy way to take care of
this one.

Comment 10 Jungshik Shin 2006-10-04 00:33:15 UTC
This bug depends on bug 175947, but it's closed as 'not a bug'....

Comment 11 Chris Lumens 2007-01-09 20:12:54 UTC
The next version will contain a potential fix for this issue - it will allow
specifying a custom rules file in the format of iptables-save that gets included
after all the default rules.  The GUI and lokkit command line interfaces support
a method of setting this parameter, but the text UI currently does not (however,
it will not nuke the setting if you add it via the command line and then run the
text interface).

Comment 12 Jon Stanley 2008-04-23 20:30:38 UTC
Adding FutureFeature keyword to RFE's.

Comment 13 Thomas Woerner 2008-05-05 12:15:57 UTC
Please use the custom rules feature of system-config-firewall, which replaced
system-config-securitylevel.

Closing as rawhide.