Re: Support for loading firewall rules with cgroup(v2) expressions early

[Topi Miettinen <toiwoton@gmail.com>]

On 28.3.2022 0.31, Pablo Neira Ayuso wrote:
> Hi,
> 
> On Sat, Mar 26, 2022 at 12:09:26PM +0200, Topi Miettinen wrote:
>> Hi,
>>
>> I'd like to use cgroupv2 expressions in firewall rules. But since the rules
>> are loaded very early in the boot, the expressions are rejected since the
>> target cgroups are not realized until much later.
>>
>> Would it be possible to add new cgroupv2 expressions which defer the check
>> until actual use? For example, 'cgroupv2name' (like iifname etc.) would
>> check the cgroup path string at rule use time?
>>
>> Another possibility would be to hook into cgroup directory creation logic in
>> kernel so that when the cgroup is created, part of the path checks are
>> performed or something else which would allow non-existent cgroups to be
>> used. Then the NFT syntax would not need changing, but the expressions would
>> "just work" even when loaded early.
> 
> Could you use inotify/dnotify/eventfd to track these updates from
> userspace and update the nftables sets accordingly? AFAIK, this is
> available to cgroupsv2.

It's possible, there's for example:
https://github.com/mk-fg/systemd-cgroup-nftables-policy-manager
https://github.com/helsinki-systems/nft_cgroupv2/

But I think that with this approach, depending on system load, there 
could be a vulnerable time window where the rules aren't loaded yet but 
the process which is supposed to be protected by the rules has already 
started running. This isn't desirable for firewalls, so I'd like to have 
a way for loading the firewall rules as early as possible.

-Topi

> 
>> Indirection through sets ('socket cgroupv2 level @lvl @cgname drop') might
>> work in some cases, but it would need support from cgroup manager like
>> systemd which would manage the sets. This would also probably not be
>> scalable to unprivileged users or containers.
>>
>> This also applies to old cgroup (v1) expression but that's probably not
>> worth improving anymore.
>>
>> Related work on systemd side:
>> https://github.com/systemd/systemd/issues/22527
>>
>> -Topi