Revert "nixos/firewall: fix reverse path check failures with IPsec" #339393
Conversation
The inclusion of the "meta ipsec" rule in the default reverse path filtering breaks systems not built with specific XFRM kernel config options. Specifically CONFIG_XFRM must be set, which gets selected by CONFIG_NFT_XFRM, which is hidden behind CONFIG_XFRM_USER. These options are not selected by default in most defconfig's provided by the kernel with the exception of some device-specific defconfigs. These options are not set by the nix kernel common_config, and I would argue that IPSec support does not belong in a minimal kernel as that elevates its support status above other in-kernel VPN interfaces. The contributor of this feature does not seem interested in working towards a solution that does not break systems running kernels built with "autoModules = false" while supporting this feature, and as this silently breaks firewalls into an insecure state and poses an immediate security issue I propose this be reverted until a solution that does not break such systems is proposed. NixOS#310857 (comment) Devices used as firewalls, if they do not have the required kernel config, will fail to load the new firewall rules and will upon boot pass traffic without any filtering into the internal network. Devices exposed directly to the internet, after reboot, will boot without filtering potentially exposing services not intended to be exposed to the internet, such as databases. The following platforms in nixpkgs appear to be impacted: - pc_simplekernel - pogoplug4 - sheevaplug - zero-gravitas - zero-sugar - utilite - guruplug - beaglebone - fuloong2f_n32 References to hardware without autoModules can be found in nixos-hardware, as well as in active third-party repos on github. I suspect there are other users impacted that do not have their configurations public, as autoModules = true leads to long compile times when targeting kernels to less standard hardware or hardware with quirks that require patches that cannot be upstreamed. This reverts commit 3c12ef3.
|
Ping @mkg20001 |
|
@mkg20001 I don't have access to merge, are you able to do that or do we need another reviewer? We should also backport to 24.05 as this was backported there. |
It's not that I'm not interested, I think it's simply not possible: to not have IPsec packets fail the reverse path check we must add these rules and the kernel must have the nft_xfrm module to load the firewall with these rules. The only way I see would be to add the rules conditionally on the kernel having the right modules. You can't inspect the kernel config file because requires IFD, I've found a couple of modules using |
|
As a temporary solution until a better one is found the rule could be added via networking.firewall.extraReversePathFilterRules by the affected users. Since this will fail validation we can keep the part Until we find the right condition to match against in kernel config or other place. Is this okay? |
|
Yes, the problem is that option is for nftables only. For iptables I think the only way is to use Anyway, I'm looking right now into the kernel |
|
I'm strongly against adding this back in as a default. It needs to go into the ipsec configuration. Additionally, I've been looking at adding a test to make sure firewall rules don't get broken by additions to the default behaviour, however on x86_64 common_config is very broken which indicates that other platforms are in a worse spot on that front and will silently ignore unknown options in common_config as It's a big impact for a router to lose its firewall rules, and they do not tend to be x86_64, so the nix default is such that the operator won't even notice the addition failed. Servers are similarly bad. Both of these are headless use-cases with varying levels of remoteness and ability to get to them to rollback boots. Not having IPsec is valid, as valid as building our kernels with |
|
There's no need to hard-code the |
Yet, the most appropriate place is the firewall module. Adding it elsewhere requires to maintain a lot of duplicated code sprinkled everywhere: there are at least 5 NixOS modules for IPsec, each needs two rules for iptables and nftables and a switch to toggle them, it's just too much. Also that would not cover other software that doesn't have a module.
If the firewall fails to load you will see a failed service and the system will show up as degraded in
Yes, and I think they're both equally unsupported. If you build a custom kernel it's on you to not break enough NixOS modules for you setup to work.
I'm not sure I understand what but it would still fail in some cases (eg. custom kernel without common-config and the module explicitly disabled, or the modules blacklisted at boot). |
Maybe there could be a common configuration option, that is disabled by default, that all 5 of these modules enable that then add a common definition to add the rules to networking.firewall.extraReversePathFilterRules and networking.nftables.preCheckRuleset.
iptables wise, I think the best way would be to add a rule to the nixos-fw-rpfilter chain in the mangle table to jump to a chain for user-defined reverse-path rules nixos-fw-rpfilter-user which could ACCEPT the traffic (as RETURN would just send it to be dropped). The rules, eg If ACCEPT isn't okay, then it's possible to get fancy with a couple MARK rules, but it wouldn't actually make it any better other than letting it RETURN from the parent chain which would implicitly turn into an ACCEPT.
They could toggle said common option as well.
It actually is very easy to not notice, and there are multiple ways in which to have this fail with no error message until AFTER the firewall fails open, potentially exposing private services, the intranet, breaking remote access (and thus rollback methods). If it's a server, there is a very real possibility someone would not notice before a database they were running was scraped by some automated crawler. I don't see how downplaying the potential impact of the failure is constructive to attempting to find a solution to adding the IPsec rules required to stop the reverse-path filtering from dropping them. Lets focus the issue at hand, adding the IPsec rules in a way that is safe.
Supported or unsupported is nuanced, however I'd appreciate it if you'd stop attempting to throw anything that doesn't fit the model of x86_64 and an all-module kernel as "unsupported" and any issue stemming from such as invalid. I have built with common_config on a tier-2 platform, it should be supported, and I'm not the only user that does this. Further, if the hardware was tier-1 this issue still would have presented itself.
I've mentioned this multiple times. There is not a kernel module to load that will tell you if there is support for that rule or not in nftables. |
Yes? |
I haven't dug into the iptables code.
That toggles an ifdef inside a module, it doesn't create a module itself, so the presence of the module does not indicate support. |
|
@nakato for testing, can you give me snippet to build a kernel the way you're doing? |
|
The inclusion of the "meta ipsec" rule in the default reverse path filtering breaks systems not built with specific XFRM kernel config options. Specifically CONFIG_XFRM must be set, which gets selected by CONFIG_NFT_XFRM, which is hidden behind CONFIG_XFRM_USER.
These options are not selected by default in most defconfig's provided by the kernel with the exception of some device-specific defconfigs.
These options are not set by the nix kernel common_config, and I would argue that IPSec support does not belong in a minimal kernel as that elevates its support status above other in-kernel VPN interfaces.
The contributor of this feature does not seem interested in working towards a solution that does not break systems running kernels built with "autoModules = false" while supporting this feature, and as this silently breaks firewalls into an insecure state and poses an immediate security issue I propose this be reverted until a solution that does not break such systems is proposed.
#310857 (comment)
Devices used as firewalls, if they do not have the required kernel config, will fail to load the new firewall rules and will upon boot pass traffic without any filtering into the internal network.
Devices exposed directly to the internet, after reboot, will boot without filtering potentially exposing services not intended to be exposed to the internet, such as databases.
The following platforms in nixpkgs appear to be impacted:
References to hardware without autoModules can be found in nixos-hardware, as well as in active third-party repos on github.
I suspect there are other users impacted that do not have their configurations public, as autoModules = true leads to long compile times when targeting kernels to less standard hardware or hardware with quirks that require patches that cannot be upstreamed.
This reverts commit 3c12ef3.