** Description changed: SRU Justification Impact: Currently, the /proc/sys/net/bridge folder is only created in the initial network namespace. This blocks use-cases where users would like to e.g. not do bridge filtering for bridges in a specific network namespace while doing so for bridges located in another network namespace. Fix: The patches linked below ensure that the /proc/sys/net/bridge folder is available in each network namespace if the module is loaded and disappears from all network namespaces when the module is unloaded. In doing so the patch makes the sysctls: bridge-nf-call-arptables bridge-nf-call-ip6tables bridge-nf-call-iptables bridge-nf-filter-pppoe-tagged bridge-nf-filter-vlan-tagged bridge-nf-pass-vlan-input-dev apply per network namespace. - Regression Potential: Low since it is limited to the br_netfilter module. - I verified that this does not lead to any regressions by compiling a kernel with those patches. I loaded and unloaded the module and verified that it works correctly for the container usecase and does not crash. - The netfilter rules are afaict already per network namespace so it should be safe for users to specify whether bridge devices inside a network namespace are supposed to go through iptables et al. or not. Also, this can already be done per-bridge by setting an option for each individual bridge via Netlink. It should also be possible to do this for all bridges in a network namespace via sysctls. + Regression Potential: Low since it is limited to the br_netfilter module. I tested the patchset extensively by compiling a kernel with the patches applied. I loaded and unloaded the module and verified that it works correctly for the container usecase and does not crash. The Google ChromeOS team has also backported this patchset to their kernel and has not seen any issues so far: https://bugs.chromium.org/p/chromium/issues/detail?id=878034 + Security considerations around netfilter rules are also low. The netfilter rules are already per network namespace so it should be safe for users to specify whether bridge devices inside a network namespace are supposed to go through iptables et al. or not. Also, this can already be done per-bridge by setting an option for each individual bridge via Netlink. It should also be possible to do this for all bridges in a network namespace via sysctls. Test Case: Tested with LXD on a kernel with the patches applied and per- network namespace iptables. Target Kernels: All LTS kernels starting from 4.15. Kernel 5.3 has the patchset upstream. Patches: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ff6d090d0db41425aef0cfe5dc58bb3cc12514a2 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=22567590b2e634247931b3d2351384ba45720ebe https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e6daf50e1f4ea0ecd56406beb64ffc66e1e94db
-- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1836910 Title: br_netfilter: namespace sysctl operations Status in linux package in Ubuntu: Fix Committed Status in linux source package in Bionic: In Progress Status in linux source package in Disco: In Progress Bug description: SRU Justification Impact: Currently, the /proc/sys/net/bridge folder is only created in the initial network namespace. This blocks use-cases where users would like to e.g. not do bridge filtering for bridges in a specific network namespace while doing so for bridges located in another network namespace. Fix: The patches linked below ensure that the /proc/sys/net/bridge folder is available in each network namespace if the module is loaded and disappears from all network namespaces when the module is unloaded. In doing so the patch makes the sysctls: bridge-nf-call-arptables bridge-nf-call-ip6tables bridge-nf-call-iptables bridge-nf-filter-pppoe-tagged bridge-nf-filter-vlan-tagged bridge-nf-pass-vlan-input-dev apply per network namespace. Regression Potential: Low since it is limited to the br_netfilter module. I tested the patchset extensively by compiling a kernel with the patches applied. I loaded and unloaded the module and verified that it works correctly for the container usecase and does not crash. The Google ChromeOS team has also backported this patchset to their kernel and has not seen any issues so far: https://bugs.chromium.org/p/chromium/issues/detail?id=878034 Security considerations around netfilter rules are also low. The netfilter rules are already per network namespace so it should be safe for users to specify whether bridge devices inside a network namespace are supposed to go through iptables et al. or not. Also, this can already be done per-bridge by setting an option for each individual bridge via Netlink. It should also be possible to do this for all bridges in a network namespace via sysctls. Test Case: Tested with LXD on a kernel with the patches applied and per-network namespace iptables. Target Kernels: All LTS kernels starting from 4.15. Kernel 5.3 has the patchset upstream. Patches: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ff6d090d0db41425aef0cfe5dc58bb3cc12514a2 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=22567590b2e634247931b3d2351384ba45720ebe https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e6daf50e1f4ea0ecd56406beb64ffc66e1e94db To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1836910/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
