<andi->
btw. in newer versions of iptables it is just a shim around nftables I believe... worth looking out for in newer releases.
<gchristensen>
oh cool
<andi->
gchristensen: runInLinuxVM would work but a bit much overhead and probably very slow... I was thinking of some kind of usermode linux not sure if that is any faster for validation. Also I do not want to use full CPU emulation because starting VMs in VMs is kinda sucky (most of the time).
<gchristensen>
:)
<andi->
The problem seems to be that nftables can be extended by random kernel modules and that syntax information isn't available in the userspace.
<andi->
It is understandable but also a design problem. If I could at least ask for basic syntax verification that would be nice.
<andi->
I am kinda used to the way `ferm` does things right now. It even has a noop way or a script generation mode
<gchristensen>
so you actually can't know at build time
<andi->
probably not everything
<andi->
you can maybe filter for keywords and valid values but only on syntax level not if they semantic makes any sense.
<gchristensen>
ah
<andi->
you can probaby write `proto foobaz` but foobaz can't be validated
<andi->
but right now the tooling only supports an all or nothing mode
<andi->
oh, > "description": "libnftables JSON API schema",
<gchristensen>
oh hi
<andi->
but that schema is more like properties = { nftables = { type = "array"; minitems = 0; items = { type = "object"; }}}… :/
ar has quit [Ping timeout: 276 seconds]
<andi->
the C implementation of the json validator seems to be a bit smarter compared to that jsonschema used in the python code.
<andi->
the json structure looks really nice when thinking of creating a NixOS module for it. Just needs a proper schema defined and/or the CLI tools to be looked at again... I'll go sleep. Maybe something to look at on some other night.
<thefloweringash>
I don't think I've ever managed to write iptables in nixos without breaking something. Due to issues like #11966, it's almost guaranteed to do the wrong thing and require manual state cleanup before running the scripts again.
<thefloweringash>
I had some plans for porting the nixos firewall to nftables, but two things get in the way. Docker doesn't support nftables, and trying to use the interop version of iptables and nftables doesn't seem to play well, since it seems like iptables-nft can create rules that nft doesn't understand, and v.v.
<thefloweringash>
The other is that nixos seems to want a half mutable half declarative firewall, which makes reloads a lot trickier than the atomic "replace all rules" that nft offers.
<gchristensen>
in what ways does it seem to want a half-mutable firewall?
<thefloweringash>
the `INPUT` chain in iptables is untouched by the scripts, except to add and remove the jump rule. So applications can smash into the main iptables chains and that's preserved through firewall reloads.
<gchristensen>
I would put money on that being just hapenstance and not by design
<thefloweringash>
and then for my efforts in supporting the half-mutable behaviour, there's a branch at `mutable-firewall` that does about 80% of the right thing.
<gchristensen>
we should almost certainly not default to the mutable firewall option
<thefloweringash>
I assumed it was to support use cases like docker or even the end user to be able to call iptables at runtime and not be reset on firewall reloads. The source doesn't seem to give much reason except "For modularity"
<gchristensen>
yeah, I can imagine a use case for enabling the mutable route
<gchristensen>
but by default it should probably not be
<gchristensen>
(enabling docker could enable the mutable thing, for example)
<thefloweringash>
hopefully I can find some time to get back to this, or at least make it PR-able
<betawaffle>
it seems like `nft -j -f stuff.json` works as you'd expect it to
<betawaffle>
hmm, i wonder if we could just run nft in a network namespace?
<betawaffle>
`unshare --net -- nft ...` seems to work
<betawaffle>
i guess that doesn't solve the non-root problem, but it's something
<flokli>
Wasn't the problem that nftables can refer to interface names, which would need to exist in whatever namespace / qemu vm you run the validation too?
<flokli>
so it's not just plain old configuration, but depends on some things present at runtime, too
<betawaffle>
yeah, it can, for sure
<betawaffle>
like iif/oif, rather than iifname/oifname, for example
<flokli>
so this can't be fully validated
<betawaffle>
without root, nope. though it would actually be impossible to some extent to *fully* validate it anyway. on a remote build machine, you don't know what interfaces the target will have at runtime
<betawaffle>
and there may be other things besides interfaces too...
<flokli>
so maybe having some syntax checker outside kernel space might make sense
<flokli>
like the nginx validator also doesn't check if the "listen" statements bind on ips actually present on the machine you want to roll this out on
<betawaffle>
and since it supports json, that should be pretty easy
<flokli>
wonder if some of the kernel code could be reused, though
<betawaffle>
they do have a library
<flokli>
either by exposing the validation functionality in the kernel (and convincing upstream it makes sense to do so), or by using kernel code via libkernel
jakobrs has left #nixos-on-your-router [#nixos-on-your-router]
<andi->
I don't think it validates interfaces names. That would make it very hard to apply rules to interfaces that might not always be there. Also they must support interfaces wildcards
<gchristensen>
you can't really validate that anyway during a build
<andi->
Yeah. I am saying we shouldn't try that
<gchristensen>
+1
<andi->
I would likely just want to verify the syntax against some JSON schema and ship it off to the cli tooling to do that actual application.
<betawaffle>
woo, apu2e4 has arrived
<gchristensen>
yay!
<gchristensen>
good luck getting anything done for the next 4h
<betawaffle>
right, i'm supposed to be working, remember
<betawaffle>
though i normally call it a day at 3pm anyway, because i start early