netdev - Re: netfilter: iptables-restore: setsockopt(3, SOL_IP, IPT_SO_SET_REPLACE, "security...", ...) return -EAGAIN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 13 May 2021 19:08:22 +0200
From:   Phil Sutter <phil@....cc>
To:     Pablo Neira Ayuso <pablo@...filter.org>
Cc:     Dexuan Cui <decui@...rosoft.com>,
        "'netfilter-devel@...r.kernel.org'" <netfilter-devel@...r.kernel.org>,
        "'netdev@...r.kernel.org'" <netdev@...r.kernel.org>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        "'linux-kernel@...r.kernel.org'" <linux-kernel@...r.kernel.org>
Subject: Re: netfilter: iptables-restore: setsockopt(3, SOL_IP,
 IPT_SO_SET_REPLACE, "security...", ...) return -EAGAIN

Hi,

On Thu, May 13, 2021 at 11:40:47AM +0200, Pablo Neira Ayuso wrote:
> On Thu, May 13, 2021 at 06:19:38AM +0000, Dexuan Cui wrote:
> > > From: Dexuan Cui
> > > Sent: Wednesday, May 12, 2021 11:02 PM
> > 
> > BTW, I found a similar report in 2019:
> > 
> > "
> > https://serverfault.com/questions/101022/error-applying-iptables-rules-using-iptables-restore
> > I stumbled upon this issue on Ubuntu 18.04. The netfilter-persistent
> > service failed randomly on boot while working ok when launched manually.
> > Turned out it was conflicting with sshguard service due to systemd trying
> > to load everything in parallel. What helped is to setting
> > ENABLE_FIREWALL=0 in /etc/default/sshguard and then adding sshguard chain
> > and rule manually to /etc/iptables/rules.v4 and /etc/iptables/rules.v6.
> > "
> > 
> > The above report provided a workaround.
> 
> There's -w and -W to serialize ruleset updates. You could follow a
> similar approach from userspace if you don't use iptables userspace
> binary.

My guess is the xtables lock is not effective here, so waiting for it
probably won't help.

Dexuan, concurrent access is avoided in user space using a file-based
lock. So if multiple iptables(-restore) processes run in different
mount-namespaces, they might miss the other's /run/xtables.lock. Another
option would be if libiptc is used instead of calling iptables, but
that's more a shot in the dark - I don't know if libiptc doesn't support
obtaining the xtables lock.

> > I think we need a real fix.
> 
> iptables-nft already fixes this.

nftables (and therefore iptables-nft) implement transactional logic in
kernel, user space automatically retries if a transaction's commit
fails.

Cheers, Phil