netdev - [Q] iptables: child user_ns: Fatal: can't open lock file /run/xtables.lock: Permission denied

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 for Android: free password hash cracker in your pocket

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

Message-ID: <2ef2150d-7149-cf39-0ea8-78edfc2c8d92@virtuozzo.com>
Date:   Fri, 9 Feb 2018 16:34:20 +0300
From:   Kirill Tkhai <ktkhai@...tuozzo.com>
To:     pablo@...filter.org,
        Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: [Q] iptables: child user_ns: Fatal: can't open lock file
 /run/xtables.lock: Permission denied

Hi,

after commit 80d8bfaac9e2430d710084a10ec78e68bd61e6ec "iptables: insist that the lock is held."
it became impossible restore to configure iptables from child user namespace:

kirill@:~/criu$ unshare -U -m -p -f -n --map-root-user --mount-proc
root@:~/criu# iptables -A INPUT -s 1.2.3.4 -j DROP
Fatal: can't open lock file /run/xtables.lock: Permission denied

iptables running inside init user ns/init net ns create the file with 0600, and others
are not able to open it.

It seems a good solution could be to use per net ns file to flock it,
and this would provide more scalability. But the problem is there is
not good one to choose. It could be someone like /proc/self/net/netfilter,
but /proc fs is made in the way, that /proc/X/net/netfilter and /proc/Y/net/netfilter
have different inodes, despite X and Y refer to the same net ns. It seems,
the only good candidate is /proc/self/ns/net, but it's too generic file
to lock it (it may be interesting not only for iptables). Not sure, we can use it.

So, it looks like the solution may be to create the file with 0666 mode by default.
This does not lose security, as it's only iptables agreement, and evil person
could just compile iptables without this file lock check. How do you think about all this?

diff --git a/iptables/xshared.c b/iptables/xshared.c
index 06db72d4..fbbe9495 100644
--- a/iptables/xshared.c
+++ b/iptables/xshared.c
@@ -254,7 +254,7 @@ static int xtables_lock(int wait, struct timeval *wait_interval)
 	time_left.tv_sec = wait;
 	time_left.tv_usec = 0;

-	fd = open(XT_LOCK_NAME, O_CREAT, 0600);
+	fd = open(XT_LOCK_NAME, O_CREAT, 0666);
 	if (fd < 0) {
 		fprintf(stderr, "Fatal: can't open lock file %s: %s\n",
 			XT_LOCK_NAME, strerror(errno));

Kirill