18 Mar 2024 |
mkg20001 | i'm thinking if there is a good way to make incus work by default | 13:53:23 |
mkg20001 | I've seen your paste aswell with the nftables rules, but I feel like the real fix is just adding a hook to lxd that it adds the trusted interface dynamically, as otherwise we end up trying to allow everything lxd wants, while lxd may or may not require something extra depending on it's settings... we could use named sets to achive the trusted interface change dynamically and temporarly | 13:53:50 |
mkg20001 | https://wiki.nftables.org/wiki-nftables/index.php/Sets#Named_sets_specifications | 13:54:28 |
mkg20001 | This. Also tables can be flushed in such a way that all sets remain with their values. | 13:54:53 |
mkg20001 | this would not only be useful for incus, but also for virsh, etc. | 13:55:43 |
mkg20001 | s/lxd/incus/ | 13:56:14 |
adamcstephens | since we're enforcing nftables now, we could also do something like
networking.nftables = {
enable = true;
tables.allow-forward = {
family = "inet";
content = ''
chain forward {
type filter hook forward priority 0;
accept
}
'';
};
};
| 13:56:27 |
adamcstephens | though i guess that doesn't help for dnsmasq | 13:57:16 |
mkg20001 | that allows all forward traffic. for all interfaces. now i need to go and deny by default any forwards from interfaces that aren't part of incus. | 13:57:58 |
mkg20001 | * that allows all forward traffic. for all interfaces. now i need to go and deny by default any forward traffic from interfaces that aren't part of incus. | 13:58:04 |
mkg20001 | if i have, say, a vpn or something else on that server | 13:58:21 |
adamcstephens | yeah | 13:58:36 |
adamcstephens | this is the problem with defaulting firewall rules :) | 13:58:44 |
mkg20001 | what do you think of the named set? should i go implement that? | 13:59:08 |
adamcstephens | so what does that look like? a table that allows a named set of interfaces for trusting, and what updates that set/ | 13:59:47 |
adamcstephens | * so what does that look like? a table that allows a named set of interfaces for trusting, and what updates that set? | 13:59:49 |
adamcstephens | how would you hook into incus/lxd? | 14:01:06 |
mkg20001 | nft add element inet nixos-fw trustedintfs { incusbr0 } is the command to add to the set | 14:02:23 |
mkg20001 | incus could support an INTERFACE_UP_HOOK / INTERFACE_DOWN_HOOK where the host os could supply the command to open the firewall for the interface, there we could use something like nft add element inet nixos-fw trustedintfs { $INTERFACE } | 14:03:15 |
adamcstephens | i wonder if this should really be handled by incus directly. they're spinning up dnsmasq on interfaces, why aren't they creating rules to allow access to it? | 14:03:51 |
mkg20001 | the problem is that in nftables an accept in one table doesn't mean the package is accepted, only that it will go to the next chain with lower priority, i think | 14:04:43 |
mkg20001 | that's why all the incus rules have policy accept set | 14:05:21 |
adamcstephens | yeah i think that's right | 14:05:26 |
adamcstephens | In reply to @mkg20001:mkg20001.io incus could support an INTERFACE_UP_HOOK / INTERFACE_DOWN_HOOK where the host os could supply the command to open the firewall for the interface, there we could use something like nft add element inet nixos-fw trustedintfs { $INTERFACE } does this hook already exist? | 14:06:36 |
mkg20001 | no. it would need to be added to incus. | 14:06:54 |
adamcstephens | maybe that's the first step then. without a hook there's not a great dynamic way for us to handle networks coming and going | 14:08:16 |
adamcstephens | also it should be flexible enough to know when dhcp is enabled on a network, because if not then we likely don't need this firewall rule | 14:11:43 |
mkg20001 | we still need to allow forward traffic and in such a way that only incus interfaces are allowed. which trustedInterface also handles. | 14:17:46 |
mkg20001 | so we'll need it always | 14:17:52 |
adamcstephens | trusted interface isn't setting a forwarding rule on my laptop | 14:22:50 |