#973439 lxc-net conflicts with iptables-persistent on boot

Package:
lxc
Source:
lxc
Description:
Linux Containers userspace tools
Submitter:
Ludwig Gramberg
Date:
2021-01-19 11:39:02 UTC
Severity:
important
Tags:
#973439#5
Date:
2020-10-30 15:10:09 UTC
From:
To:
Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

when lxc-net and netfilter/iptables-persistent are installed the start-up script
in lxc-net uses iptables-commands while iptables-restore is used by netfilter-persistent.
this is an unstable situation which sometimes causes iptables-restore to fail on COMMIT.
thus the iptables rules are not being loaded leaving the server vulnerable.

this should be solved within the service-files of systemd. if netfilter-persistent.service
only runs after lxc-net.service the conflict should be avoided. at least it helped on my server.

*** End of the template - remove these template lines ***

#973439#10
Date:
2021-01-19 09:38:53 UTC
From:
To:
Le vendredi 30 octobre 2020 à 16:10:09+0100, Ludwig Gramberg a écrit :

Dear Ludwig,

Thanks for your bug report. The issue does not seem that easy to tackle.
Indeed, if you start netfilter-persistent after lxc-net, you lose the
lxc-net firewall configurations you've made, as netfilter-persistent
overrides the rules set in place by lxc-net.

Apart from that, have you experienced this issue in the current stable
release?

Cheers!

#973439#19
Date:
2021-01-19 10:20:41 UTC
From:
To:
Hi Pierre-Elliot,

it’s not that you lose rules set by lxc-net, you basically have a race-condition.

lxc-net is setting rules directly by calling iptables commands, setting one rule at a time.
iptables-persistent on the other hand is using the iptables-restore command and these don’t mix.
If anyone is setting rules in iptables while the restore-command is running the restore-command fails.

So it is not about overwriting each other its about the restore failing entirely.
I would be happy if the restore „would win“ but it utterly fails leaving the server without its most important basic set of firewall-rules.
This is why I categorized this as severe.

The problem can happen with any combination where a process sets firewall rules early in the boot-process while netfilter-persistent is doing its restore.

Last I have seen this in Debian 9 happening and have not yet tested this in Debian 10 (doesn't Deb10 use nftables which is profoundly different?)

kind regards
Ludwig

#973439#24
Date:
2021-01-19 11:24:24 UTC
From:
To:
Le mardi 19 janvier 2021 à 11:20:41+0100, Ludwig Gramberg a écrit :
between two packages that poses some security concerns, but it's not a
CVE, an it's not a daily case for everyone.

I'm eager to tackle it without putting an unneeded Conflicts/Breaks:
entry on lxc, but it remains something a system administrator has to
handle and check when one installs such programs.

So actually the good solution would be for netfilter-persistent to be
fully started *before* lxc-net tries to start, am I right?

We could probably try to do that with systemd files.

Both alternatives are present on Debian 10 (iptables and nftables).

#973439#29
Date:
2021-01-19 11:30:10 UTC
From:
To:
I am new to reporting debian bugs so I follow your advice concerning the severity ;-)

changing systemd-files was also my solution (creating a dependency)

better would be if netfilter-persistent would move to a point in boot when no other iptables-touching software would run, but idk if this is even possible