Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1043278 > unrolled thread

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

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#973439: lxc-net conflicts with iptables-persistent on boot Pierre-Elliott Bécue <peb@debian.org> - 2021-01-19 11:00 +0100
    Bug#973439: lxc-net conflicts with iptables-persistent on boot Ludwig Gramberg <info@ludwig-gramberg.de> - 2021-01-19 11:40 +0100
      Bug#973439: lxc-net conflicts with iptables-persistent on boot Pierre-Elliott Bécue <peb@debian.org> - 2021-01-19 12:30 +0100
        Bug#973439: lxc-net conflicts with iptables-persistent on boot Ludwig Gramberg <info@ludwig-gramberg.de> - 2021-01-19 12:40 +0100

#1043278 — Bug#973439: lxc-net conflicts with iptables-persistent on boot

[Multipart message — attachments visible in raw view] — view raw

Control: severity -1 important
Control: tags -1 +stretch

Le vendredi 30 octobre 2020 à 16:10:09+0100, Ludwig Gramberg a écrit :
> 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.

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!

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.

[toc] | [next] | [standalone]

#1043294

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

> Am 19.01.2021 um 10:38 schrieb Pierre-Elliott Bécue <peb@debian.org>:
> 
> Control: severity -1 important
> Control: tags -1 +stretch
> 
> Le vendredi 30 octobre 2020 à 16:10:09+0100, Ludwig Gramberg a écrit :
>> 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.
> 
> 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!
> 
> -- 
> Pierre-Elliott Bécue
> GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
> It's far easier to fight for one's principles than to live up to them.

[toc] | [prev] | [next] | [standalone]

#1043305

[Multipart message — attachments visible in raw view] — view raw

Le mardi 19 janvier 2021 à 11:20:41+0100, Ludwig Gramberg a écrit :
> 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.

IMHO your choice of severity was too strong. This is an incompatibility
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.

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

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.

> 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?)

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

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.

[toc] | [prev] | [next] | [standalone]

#1043307

[Multipart message — attachments visible in raw view] — view raw

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

> Am 19.01.2021 um 12:24 schrieb Pierre-Elliott Bécue <peb@debian.org>:
> 
> Le mardi 19 janvier 2021 à 11:20:41+0100, Ludwig Gramberg a écrit :
>> 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.
> 
> IMHO your choice of severity was too strong. This is an incompatibility
> 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.
> 
>> 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.
> 
> 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.
> 
>> 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?)
> 
> Both alternatives are present on Debian 10 (iptables and nftables).
> 
> -- 
> Pierre-Elliott Bécue
> GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
> It's far easier to fight for one's principles than to live up to them.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web