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: 2020-03-02 09:17 CET (History)
13 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

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

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 Jybz 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

Comment 14 Luděk Janča 2019-01-15 12:30:51 CET
Workaround with uninstalling of mandi doesn't work for me. Only working workaround is remove long interface from

/etc/shorewall6/interfaces
/etc/shorewall/interfaces

After that, shorewall(6) starts properly.

CC: (none) => joelp

Comment 15 Stig-Ørjan Smelror 2019-02-14 20:21:41 CET
The code in /usr/include/linux/if.h says:

#if __UAPI_DEF_IF_IFNAMSIZ
#define IFNAMSIZ        16
#endif /* __UAPI_DEF_IF_IFNAMSIZ */
#define IFALIASZ        256

Why can't we then use IFALIASZ instead or check if the name is too long and then use it?

I'm no programmer, but like mentioned in comment #13, this should me changed or hacked somehow.

Cheers,
Stig

CC: (none) => smelror

Comment 16 Dave Hodgins 2019-02-16 00:25:08 CET
Options for dealing with this bug.

1) Fix drakfirewall so that when it configures mandi-ifw, it doesn't try to
use the ssid where shorewall expects an interface name, as the ssid can
be too long. If something unique to the wireless access point is needed,
use something shorter such as the mac address.

2) Modify shorewall to allow an interface name that's longer (256 bytes).

3) Remove the option to try to use the ifw from drakfirewall, since it may
set up the ifw with broken configurations anyway.

4) Drop the packages drakfirewall, mandi, and mandi-ifw.

5) Leave everything as is, knowing that the existing system breaks shorewall
if the system is configured to access a wireless access point with an ssid
that is over 15 bytes in length.

After 6 years, I don't want to see yet another release go out with option 5.
Comment 17 Luděk Janča 2019-10-01 11:26:10 CEST
The same problem on WIFI with SSID shorter than 15 chars. If you have more APs with same SSID, it produce interfaces like 14CHARSSID-1, 14CHARSSID-2, ... 14CHARSSID-N. What leads to have more than 15 chars internaface name.
Comment 18 gilles d 2020-02-24 16:08:22 CET
Hi,
Nice bug report, very useful, as I found today why I had to remove completely the firewall if I wanted to allow remote backup of my laptop by my university. Which was bad in terms of security, is not it?
This because I got as a disease a SSID longer than 15 characters.
So the bug is still present as of Feb 2020.

I humbly suggests to edit drakfirewall to any of the valid options above, even option "get rid of drakfirewall and propose something else".

and keep on the good work (i.e. almost everything else!)

CC: (none) => gilles.duvert

Comment 19 Dave Hodgins 2020-02-24 23:25:35 CET
It's not suggesting getting rid of the firewall, just the part called the
interactive firewall. Removing the package mandi-ifw and mandi, is all that's
needed. The shorewall package still controls the loading of the rules for
internet traffic (aka firewall rules). In linux, the actual firewall is called
netfilter, and is part of the kernel.
Comment 20 gilles d 2020-02-25 11:47:49 CET
Thanks for clarifying.
However, at some point in the click an point process in the Mageia Control Center, I unchecked "Use Interactive Firewall" but the problem was still there. So it was not obvious the problem was on the interactive firewall side.

The only way out was to remove the connection with a very long name using "Remove a Connection" (in the Network and Internet tab) before going to the "Security" tab and "Set up your personal firewall". Or, of course, not using MCC and remove the long 15+ culprit chain in /etc/shorewall/interface.
Comment 21 Luděk Janča 2020-02-25 12:55:13 CET
(In reply to Dave Hodgins from comment #19)
> It's not suggesting getting rid of the firewall, just the part called the
> interactive firewall. Removing the package mandi-ifw and mandi, is all that's
> needed. The shorewall package still controls the loading of the rules for
> internet traffic (aka firewall rules). In linux, the actual firewall is
> called
> netfilter, and is part of the kernel.

That's not true. I have no packages mandi-ifw or mandi and shorewall not works with log interface names

#journalctl -u shorewall
iptables-restore v1.8.2 (legacy): interface name `SOME-LOG-SSID-NAME' must be shorter than IFNAMSIZ (15)
úno 25 12:47:53 localhost.localdomain shorewall[12265]: Error occurred at line: 124
úno 25 12:47:53 localhost.localdomain shorewall[12265]: Try `iptables-restore -h' or 'iptables-restore --help' for more information.
úno 25 12:47:53 localhost.localdomain shorewall[12265]:    ERROR: iptables-restore Failed. Input is in /var/lib/shorewall/.iptables-restore-input
úno 25 12:47:53 localhost.localdomain root[12738]: ERROR:Shorewall start failed
Comment 22 Dave Hodgins 2020-02-25 14:27:40 CET
(In reply to Luděk Janča from comment #21)
> That's not true. I have no packages mandi-ifw or mandi and shorewall not
> works with log interface names
> 
> #journalctl -u shorewall
> iptables-restore v1.8.2 (legacy): interface name `SOME-LOG-SSID-NAME' must
> be shorter than IFNAMSIZ (15)

What created that rule? The interface name should be something like eth0,
or enp2s0, or p32p1. If you don't use mandi, then what created that rule?

It's supposed to be the name of the network device, not an ssid. Shorewall
only uses it for the messages it generates, so the mandi author(s) decided
to put the ssid in that field for the messages, but it fails with an ssid
name that is longer than what a network interface name is limited to, which
makes mandi generate rules that shorewall cannot process.
Comment 23 Luděk Janča 2020-03-02 09:17:32 CET
(In reply to Dave Hodgins from comment #22)
> (In reply to Luděk Janča from comment #21)
> > That's not true. I have no packages mandi-ifw or mandi and shorewall not
> > works with log interface names
> > 
> > #journalctl -u shorewall
> > iptables-restore v1.8.2 (legacy): interface name `SOME-LOG-SSID-NAME' must
> > be shorter than IFNAMSIZ (15)
> 
> What created that rule? The interface name should be something like eth0,
> or enp2s0, or p32p1. If you don't use mandi, then what created that rule?
> 
> It's supposed to be the name of the network device, not an ssid. Shorewall
> only uses it for the messages it generates, so the mandi author(s) decided
> to put the ssid in that field for the messages, but it fails with an ssid
> name that is longer than what a network interface name is limited to, which
> makes mandi generate rules that shorewall cannot process.

Looks like that interfaces were from the past. After that I deleted interfaces, shorewall works well. Using NetworkManager. For now, it's needed to do not use interactive firewall.

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