News for hackers. Stuff that matters.
Re:The Firewall Doesn't Live in the Kernel by theamk on Tuesday March 17, 2026 @11:12AM (#47413813)
Author makes a point that since (rather complex) firewall configuration parsing is all in userland, we can't say that the firewall lives in the kernel.

Disagree - practically every single kernel feature is configured from userland. Kernel provides filesystem, but userland calls "mount". Kernel routes packets, but userland sets up interfaces. Even something as direct as loading a device driver is now mediated by udev in userland. And yet, we say that filesystems, routing and device drives all live in the kernel.

(Also a note to the author on the post itself: it seems like the post is unsure what its purpose is. It could be a cool overview of how firewall config works, or a thought piece about configuration boundaries, or warning about unexpected interaction between kernel and privileged daemons... but right now it's kinda a mix of all of those and it makes it a bit hard to read. Maybe trust LLMs less and apply more human guidance when writing the posts?)

Re:The Firewall Doesn't Live in the Kernel by IcePic on Wednesday March 18, 2026 @06:48AM (#47423969)
Yeah, someone wrote along the lines of "userland sets the rules, the kernel enforces them" which I thought was a neat short version.
Re:The Firewall Doesn't Live in the Kernel by becker63 on Tuesday March 17, 2026 @10:48AM (#47413490)
Author here.

This came out of building a structured fuzzer around libnftnl and trying to understand where firewall semantics actually get fixed in the stack.

Curious how this lines up with others’ mental models of nftables.

Re:The Firewall Doesn't Live in the Kernel by dlcarrier on Tuesday March 17, 2026 @01:57PM (#47416013)
Having any of the firewall in the kernel is one Linuxism I've never understood. I tried to set up an old computer as a VPN server, and I had to recompile the kernel or switch distributions, because the kernel wasn't compiled with a packet processing feature I wanted to use.