* userns packet mangling
@ 2026-10-16 20:18 Richard Van Tassel
2026-10-16 22:51 ` Florian Westphal
0 siblings, 1 reply; 3+ messages in thread
From: Richard Van Tassel @ 2026-10-16 20:18 UTC (permalink / raw)
To: netfilter
Hello, netfilter world.
I am very curious about the status of re-enabling packet mangling in
user namespaces.
I understand that it takes time to find and address security concerns,
and I hope the netfilter community takes all the time they need. That
being said, I just wanted to echo the appetite for that functionality
to return, similar to
582d218b638be68342dd80893c41746b35c1be76.camel@student.kit.edu (sorry
if I'm linking this incorrectly, I haven't used this sort of mailing
list before)
I am currently working around the disabling in a somewhat controlled
fashion using a custom kernel patch and module to allow a process in
init ns with CAP_NET_ADMIN to grant permission to mangle on a per-ns
basis. As I understand the situation currently, I don't think there's
much appetite for accepting this workaround as a kernel contribution,
since the disabling is meant to be temporary. But I feel like I should
mention it nevertheless.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: userns packet mangling
2026-10-16 20:18 userns packet mangling Richard Van Tassel
@ 2026-10-16 22:51 ` Florian Westphal
2026-10-17 9:04 ` Pablo Neira Ayuso
0 siblings, 1 reply; 3+ messages in thread
From: Florian Westphal @ 2026-10-16 22:51 UTC (permalink / raw)
To: Richard Van Tassel; +Cc: netfilter
Richard Van Tassel <richard.van.tassel.work@gmail.com> wrote:
> Hello, netfilter world.
>
> I am very curious about the status of re-enabling packet mangling in
> user namespaces.
>
> I understand that it takes time to find and address security concerns,
> and I hope the netfilter community takes all the time they need. That
> being said, I just wanted to echo the appetite for that functionality
> to return, similar to
> 582d218b638be68342dd80893c41746b35c1be76.camel@student.kit.edu (sorry
> if I'm linking this incorrectly, I haven't used this sort of mailing
> list before)
> I am currently working around the disabling in a somewhat controlled
> fashion using a custom kernel patch and module to allow a process in
> init ns with CAP_NET_ADMIN to grant permission to mangle on a per-ns
> basis. As I understand the situation currently, I don't think there's
> much appetite for accepting this workaround as a kernel contribution,
> since the disabling is meant to be temporary. But I feel like I should
> mention it nevertheless.
https://patchwork.ozlabs.org/project/netfilter-devel/patch/20260905050150.30273-1-fw@strlen.de/
is still pending, and its closing known security hole.
So no, for now we can't re-enable this feature.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: userns packet mangling
2026-10-16 22:51 ` Florian Westphal
@ 2026-10-17 9:04 ` Pablo Neira Ayuso
0 siblings, 0 replies; 3+ messages in thread
From: Pablo Neira Ayuso @ 2026-10-17 9:04 UTC (permalink / raw)
To: Florian Westphal; +Cc: Richard Van Tassel, netfilter
On Sat, Oct 17, 2026 at 12:51:05AM +0200, Florian Westphal wrote:
> Richard Van Tassel <richard.van.tassel.work@gmail.com> wrote:
> > Hello, netfilter world.
> >
> > I am very curious about the status of re-enabling packet mangling in
> > user namespaces.
> >
> > I understand that it takes time to find and address security concerns,
> > and I hope the netfilter community takes all the time they need. That
> > being said, I just wanted to echo the appetite for that functionality
> > to return, similar to
> > 582d218b638be68342dd80893c41746b35c1be76.camel@student.kit.edu (sorry
> > if I'm linking this incorrectly, I haven't used this sort of mailing
> > list before)
>
> > I am currently working around the disabling in a somewhat controlled
> > fashion using a custom kernel patch and module to allow a process in
> > init ns with CAP_NET_ADMIN to grant permission to mangle on a per-ns
> > basis. As I understand the situation currently, I don't think there's
> > much appetite for accepting this workaround as a kernel contribution,
> > since the disabling is meant to be temporary. But I feel like I should
> > mention it nevertheless.
>
> https://patchwork.ozlabs.org/project/netfilter-devel/patch/20260905050150.30273-1-fw@strlen.de/
>
> is still pending, and its closing known security hole.
> So no, for now we can't re-enable this feature.
I will pick this in the next nf.git PR.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-10-17 9:04 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-10-16 20:18 userns packet mangling Richard Van Tassel
2026-10-16 22:51 ` Florian Westphal
2026-10-17 9:04 ` Pablo Neira Ayuso
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.