Description of Problem: With redhat-config-securitylevel-0.9.9-1, if the user chooses to set up a custom firewall, the settings aren't getting passed back to the iptables config file. Version-Release number of selected component (if applicable): How Reproducible: Steps to Reproduce: 1. Run redhat-config-securitylevel 2. Select 'Custom' and configure something (allow web access for example) 3. Save your changes 4. Run 'iptables -L -n -v' to see the results of your changes Actual Results: Configured rules won't match what you just input. Actually appears that we are merging together the rules from whatever level is selected (high, medium, no) with the customizations you are making. This can be confirmed by setting it to "No firewall" and then saving changes (as you will see the error talked about in bug #70807) Expected Results: Additional Information:
Hmm, this actually works for me. Can you try again and maybe attach the output of 'iptables -L -n -v' before and after running the program. Here's what I see after selecting --medium and customizing allow eth0, www, Mail, and Telnet: [root@aspen src]# /sbin/iptables -L -n -v Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 RH-Lokkit-0-50-INPUT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain RH-Lokkit-0-50-INPUT (1 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 flags:0x16/0x02 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 flags:0x16/0x02 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:23 flags:0x16/0x02 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- eth0 * 0.0.0.0/0 0.0.0.0/0 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:0:1023 flags:0x16/0x02 reject-with icmp-port-unreachable 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:2049 flags:0x16/0x02 reject-with icmp-port-unreachable 0 0 REJECT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:0:1023 reject-with icmp-port-unreachable 0 0 REJECT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:2049 reject-with icmp-port-unreachable 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:6000:6009 flags:0x16/0x02 reject-with icmp-port-unreachable 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:7100 flags:0x16/0x02 reject-with icmp-port-unreachable It seems that it is accepting requests on device eth0 and on ports 80, 25, and 23. Isn't this the correct behavior? However, bug #70807 is still valid.
OK, I think that we have an interface issue then. The way that I look at that screen, the user should either be able to select a security level, or create one of their own (using the customize option.) The biggest reason that I think this, is that the user is never shown just what a "medium" firewall is for example. How do I customize something when I don't even know where I'm starting? So, the motivation behind this bug report was that I wasn't aware that the tool was combining the security level with the customizations that I was making. I was thinking that if I said "customize" and then only selected www access, then the resulting iptables rules would reflect that only traffic on port 80 was allowed into the system. Might be worth a discussion with a couple of others . . . I could just be off in left-field with these thoughts.
OK, this appears to be working as stated, but I still find it pretty confusing for the normal user that is just trying to set up a firewall and not having any concept of just what 'medium' or 'high' means. So, I'm deferring this and hoping that we will revisit in the next round of config tools revamping.