Bug 8960 - drakfirewall adds lines longer than IFNAMSIZ (15)-1 to /etc/shorewall/interfaces
Summary: drakfirewall adds lines longer than IFNAMSIZ (15)-1 to /etc/shorewall/interfaces
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: High major
Target Milestone: Mageia 6
Assignee: Mageia tools maintainers
QA Contact:
URL:
Whiteboard:
Keywords:
: 9015 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-02-04 21:12 CET by Jim Dines
Modified: 2018-03-14 11:52 CET (History)
10 users (show)

See Also:
Source RPM: mandi-1.4-2.mga6
CVE:
Status comment:


Attachments

Description Jim Dines 2013-02-04 21:12:34 CET
Description of problem:

When you connect to a WiFi network with a long SSID (>=15 Characters) and then configure your firewall it adds a loc entry to /etc/shorewall/interfaces that is too long for shorewall to handle.  It will break shorewall, but drakfirewall will still claim everything is OK :-(

Version-Release number of selected component (if applicable):

Probably every version since drakfirewall was created?

I'm calling it a major/critical issue since drakfirewall doesn't even let the user know his firewall is now down.
Comment 1 Bit Twister 2013-02-05 06:25:51 CET
(In reply to comment #0)

> I'm calling it a major/critical issue since drakfirewall doesn't even let the
> user know his firewall is now down.

I can agree that a status of shorewall should be returned since the default
is no firewall.
That is a poor decision in my opinion because of all the services that are running, not to mention systemd starting services it updates even though you have stopped them.

CC: (none) => junk_no_spam

Manuel Hiebel 2013-02-10 13:52:28 CET

Assignee: bugsquad => mageia

Comment 2 Thierry Vignaud 2013-02-19 20:24:07 CET
*** Bug 9015 has been marked as a duplicate of this bug. ***

CC: (none) => dag

Comment 3 Nic Baxter 2015-02-25 03:43:50 CET
Has this been resolved? 2 years since last comment.

CC: (none) => nic

Comment 4 Manuel Hiebel 2015-02-28 00:21:23 CET
looks I can reproduce, and so shorewall don't want to start :(

févr. 28 00:16:09 linux drakfirewall[16709]: running: /bin/mountpoint -q /sys/fs/cgroup/systemd
févr. 28 00:16:09 linux drakfirewall[16709]: running: /bin/systemctl --quiet is-active mandi.service
févr. 28 00:16:09 linux drakfirewall[16709]: launched command: killall -s SIGUSR1 net_applet
févr. 28 00:16:09 linux drakfirewall[16709]: ### Program is exiting ###
févr. 28 00:16:09 linux shorewall[16995]: Compiling...
févr. 28 00:16:09 linux shorewall[16995]: Processing /etc/shorewall/params ...
févr. 28 00:16:09 linux shorewall[16995]: Processing /etc/shorewall/shorewall.conf...
févr. 28 00:16:09 linux shorewall[16995]: Loading Modules...
févr. 28 00:16:09 linux shorewall[16995]: Compiling /etc/shorewall/zones...
févr. 28 00:16:09 linux shorewall[16995]: Compiling /etc/shorewall/interfaces...
févr. 28 00:16:10 linux shorewall[16995]: Determining Hosts in Zones...
févr. 28 00:16:10 linux shorewall[16995]: Locating Action Files...
févr. 28 00:16:10 linux shorewall[16995]: Compiling /etc/shorewall/policy...
févr. 28 00:16:10 linux shorewall[16995]: Running /etc/shorewall/initdone...
févr. 28 00:16:10 linux shorewall[16995]: Compiling TCP Flags filtering...
févr. 28 00:16:10 linux shorewall[16995]: Compiling Kernel Route Filtering...
févr. 28 00:16:10 linux shorewall[16995]: Compiling Martian Logging...
févr. 28 00:16:10 linux shorewall[16995]: Compiling MAC Filtration -- Phase 1...
févr. 28 00:16:10 linux shorewall[16995]: Compiling /etc/shorewall/policy...
févr. 28 00:16:10 linux shorewall[16995]: Running /etc/shorewall/initdone...
févr. 28 00:16:10 linux shorewall[16995]: Compiling TCP Flags filtering...
févr. 28 00:16:10 linux shorewall[16995]: Compiling Kernel Route Filtering...
févr. 28 00:16:10 linux shorewall[16995]: Compiling Martian Logging...
févr. 28 00:16:10 linux shorewall[16995]: Compiling MAC Filtration -- Phase 1...
févr. 28 00:16:10 linux shorewall[16995]: Compiling /etc/shorewall/rules...
févr. 28 00:16:10 linux shorewall[16995]: Compiling /etc/shorewall/conntrack...
févr. 28 00:16:10 linux shorewall[16995]: Compiling MAC Filtration -- Phase 2...
févr. 28 00:16:10 linux shorewall[16995]: Applying Policies...
févr. 28 00:16:10 linux shorewall[16995]: Compiling /usr/share/shorewall/action.Drop for chain Drop...
févr. 28 00:16:10 linux shorewall[16995]: Compiling /usr/share/shorewall/action.Broadcast for chain Broadcast...
févr. 28 00:16:10 linux shorewall[16995]: Generating Rule Matrix...
févr. 28 00:16:10 linux shorewall[16995]: Compiling /usr/share/shorewall/action.Reject for chain Reject...
févr. 28 00:16:10 linux shorewall[16995]: Creating iptables-restore input...
févr. 28 00:16:10 linux shorewall[16995]: Shorewall configuration compiled to /var/lib/shorewall/.start
févr. 28 00:16:10 linux shorewall[16995]: Starting Shorewall....
févr. 28 00:16:10 linux shorewall[16995]: Initializing...
févr. 28 00:16:10 linux shorewall[16995]: Processing /etc/shorewall/init ...
févr. 28 00:16:10 linux shorewall[16995]: Processing /etc/shorewall/tcclear ...
févr. 28 00:16:10 linux shorewall[16995]: Setting up Route Filtering...
févr. 28 00:16:10 linux shorewall[16995]: Setting up Martian Logging...
févr. 28 00:16:10 linux shorewall[16995]: Setting up Proxy ARP...
févr. 28 00:16:10 linux shorewall[16995]: Preparing iptables-restore input...
févr. 28 00:16:10 linux shorewall[16995]: Running /sbin/iptables-restore...
févr. 28 00:16:10 linux shorewall[16995]: iptables-restore v1.4.21: interface name `Auto_freebox_WDURIO' must be shorter than IFNAMSIZ (15)
févr. 28 00:16:10 linux shorewall[16995]: Error occurred at line: 88
févr. 28 00:16:10 linux shorewall[16995]: Try `iptables-restore -h' or 'iptables-restore --help' for more information.
févr. 28 00:16:10 linux shorewall[16995]: ERROR: iptables-restore Failed. Input is in /var/lib/shorewall/.iptables-restore-input
févr. 28 00:16:10 linux logger[17228]: ERROR:Shorewall start failed
févr. 28 00:16:10 linux shorewall[16995]: Processing /etc/shorewall/stop ...
févr. 28 00:16:10 linux shorewall[16995]: iptables v1.4.21: Couldn't load target `Ifw':No such file or directory
févr. 28 00:16:10 linux shorewall[16995]: Try `iptables -h' or 'iptables --help' for more information.
févr. 28 00:16:10 linux shorewall[16995]: iptables: No chain/target/match by that name.
févr. 28 00:16:10 linux shorewall[16995]: iptables: No chain/target/match by that name.
févr. 28 00:16:10 linux shorewall[16995]: ipset v6.24: The set with the given name does not exist
févr. 28 00:16:10 linux shorewall[16995]: ipset v6.24: The set with the given name does not exist
févr. 28 00:16:10 linux shorewall[16995]: Processing /etc/shorewall/tcclear ...
févr. 28 00:16:10 linux shorewall[16995]: Running /sbin/iptables-restore...
févr. 28 00:16:10 linux shorewall[16995]: Processing /etc/shorewall/stopped ...
févr. 28 00:16:10 linux logger[17255]: Shorewall Stopped
févr. 28 00:16:10 linux shorewall[16995]: /usr/share/shorewall/lib.common : ligne 113 : 17183 Complété              $SHOREWALL_SHELL $script $options $@
févr. 28 00:16:10 linux systemd[1]: shorewall.service: main process exited, code=exited, status=143/n/a
févr. 28 00:16:10 linux systemd[1]: Failed to start Shorewall IPv4 firewall.
Comment 5 Manuel Hiebel 2015-02-28 00:23:39 CET
and using nm which add auto_ to my ssid freebox_wdurio

CC: (none) => mageia, olav, thierry.vignaud

Comment 6 Manuel Hiebel 2015-02-28 00:29:35 CET
in fact nm create /etc/sysconfig/network-scripts/ifcfg-Auto_freebox_wdurio
and drakfirewall think it is an interface (or it is one for networkmanager world ?)
Comment 7 Manuel Hiebel 2015-02-28 00:58:16 CET
if I remove the ifcfg file everything seems to work
Curtis Hildebrand 2016-05-28 08:17:39 CEST

CC: (none) => curtis_mageia

Comment 8 Curtis Hildebrand 2016-10-12 08:07:21 CEST
I just realized I was bitten by this bug again.

To recap (using my situation as an example if I get this right):
- On my laptop, I connected to a wifi at a local brewery.  I'm using NetworkManager, but draknet is still configured.

- The SSID is longer than 15 characters ("Field House Brewing - Public").

- files are created in /etc/sysconfig/network-scripts
    "ifcfg-Auto_Field_House_Brewing_-_Public"
    "keys-ifcfg-Auto_Field_House_Brewing_-_Public"

- drakfirewall adds an entry to /etc/shorewall/interfaces
     Auto_Field_House_Brewing_-_Public

- shorewall restarts resulting in the SILENT error (only shows on the commandline)
     iptables-restore v1.6.0: interface name `Auto_Field_House_Brewing_-_Public' must be shorter than IFNAMSIZ (15)

- Since there was no error, the user continues working with NO FIREWALL!


My workaround (not sure if all the steps are needed):
- shorten all NetworkManager WiFi names that are longer than 15 characters
    #nmcli con show   (to get the list of saved settings)
- rename all the ifcg-* files to match the NM names with "ifcfg-" at the beginning
- rename the keys-* files to match the ifcfg-* files
- run drakfirewall.  I'm able to just click OK through all the options.
- test the firewall settings with "shorewall show" on the cmd line
- if needed, run "shorewall restart"


Seems like a pretty serious security issue to silently leave a user hanging with a wide open network connection (no firewall).
Samuel Verschelde 2016-10-12 09:34:56 CEST

Assignee: mageia => mageiatools
Target Milestone: --- => Mageia 6
Priority: Normal => High

Comment 9 Mika Laitio 2016-12-17 03:30:55 CET
Having been hitten by this bug also a couple of time. For example the free access points in some airports are over 15 char... Once you have those long access point names listed on /etc/shoreline/interfaces, shoreline will fail to start silently.

CC: (none) => lamikr

Comment 10 Dag Nygren 2017-03-29 12:28:26 CEST
Just ran into this again. How come this is still a problem?
Comment 11 Mika Laitio 2017-11-09 09:02:00 CET
I am using a mga6 with gnome and I select the wlan via gnome's menu.
(instead of using drakconf for wifi selections) At least in this way the SSID's ends up to be added automatically to /etc/shorewall/interfaces file.
 
At least for me the 15 char defined by the IFNAMSIZ is the limit (remembered incorrectly on previous mail that it was 20 chars)

So if I add to /etc/shorewall/interfaces
   
       net     012345678912345  detect

shorewall will still be able to start ok with command 
   systemctl restart shorewall.service

But if I instead add
      net     0123456789123456  detect

systemctl restart shorewall.service fails and 
systemctl status shorewall.service 
● shorewall.service - Shorewall IPv4 firewall
   Loaded: loaded (/usr/lib/systemd/system/shorewall.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Wed 2017-11-08 23:51:48 PST; 5min ago
  Process: 19823 ExecStop=/sbin/shorewall $OPTIONS stop (code=exited, status=0/SUCCESS)
  Process: 19891 ExecStart=/sbin/shorewall $OPTIONS start $STARTOPTIONS (code=exited, status=143)
 Main PID: 19891 (code=exited, status=143)

Nov 08 23:51:48 localhost.localdomain shorewall[19891]: ipset v6.30: The set with the given name does not exist
Nov 08 23:51:48 localhost.localdomain shorewall[19891]: Processing /etc/shorewall/tcclear ...
Nov 08 23:51:48 localhost.localdomain shorewall[19891]: Preparing iptables-restore input...
Nov 08 23:51:48 localhost.localdomain shorewall[19891]: Running /sbin/iptables-restore...
Nov 08 23:51:48 localhost.localdomain shorewall[19891]: Processing /etc/shorewall/stopped ...
Nov 08 23:51:48 localhost.localdomain shorewall[19891]: /usr/share/shorewall/lib.common: line 93: 20090 Terminated              $SHOREWALL_SHELL $
Nov 08 23:51:48 localhost.localdomain systemd[1]: shorewall.service: Main process exited, code=exited, status=143/n/a
Nov 08 23:51:48 localhost.localdomain systemd[1]: Failed to start Shorewall IPv4 firewall.
Nov 08 23:51:48 localhost.localdomain systemd[1]: shorewall.service: Unit entered failed state.
Nov 08 23:51:48 localhost.localdomain systemd[1]: shorewall.service: Failed with result 'exit-code'.
Comment 12 Dave Hodgins 2017-11-11 07:49:31 CET
I'm pretty sure (but not positive) the problem is in
http://gitweb.mageia.org/software/mandi/tree/src/plugins/ifw/ipset.c

The package no longer has a maintainer. Unless this problem can be fixed,
I'll be recommending that mandi be dropped from Mageia 7.

The workaround for now is to uninstall mandi and mandi-ifw. You will no
longer get the notifications of someone running a port scan against you,
etc., but at least shorewall will not be disabled. Note that when using
mcc to configure the firewall, select cancel when it asks to install mandi.

Source RPM: drakx-net-text-1.18-1.mga3 => mandi-1.4-2.mga6
CC: (none) => davidwhodgins

Comment 13 J-B B 2018-03-14 11:52:51 CET
Hi guys

I used networkmanager first than I came back on draknet, and tried again networkmanager because it seems to be the one by default, etc...

And they didn't like to be connect on the same wifi which is 14 char long, and networkmanager renamed it by appending "-1" at the end. Now it is 16 char long, and the firewall is not available anymore.

One work around suggested was uninstalling mandi. I look on the SC given by Dave Hodgins, and I wonder why not changing IFNAMSIZ from 16 to 32 ?
I saw it here /usr/include/linux/if.h LINE 31 : #define IFNAMSIZ 16

Now the wifi name are much bigger than before, isn't it time to increase this limit ?
Or, changing mandi with a dynamic length instead of a fixed one ?

Jibz

CC: (none) => j.biernacki


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