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

[Topi Miettinen <toiwoton@gmail.com>]

On 30.3.2022 5.53, Pablo Neira Ayuso wrote:
> On Wed, Mar 30, 2022 at 12:25:25AM +0200, Pablo Neira Ayuso wrote:
>> On Tue, Mar 29, 2022 at 09:20:25PM +0300, Topi Miettinen wrote:
> [...]
>> You could define a ruleset that describes the policy following the
>> cgroupsv2 hierarchy. Something like this:
>>
>>   table inet filter {
>>          map dict_cgroup_level_1 {
>>                  type cgroupsv2 : verdict;
>>                  elements = { "system.slice" : jump system_slice }
>>          }
>>
>>          map dict_cgroup_level_2 {
>>                  type cgroupsv2 : verdict;
>>                  elements = { "system.slice/systemd-timesyncd.service" : jump systemd_timesyncd }
>>          }
>>
>>          chain systemd_timesyncd {
>>                  # systemd-timesyncd policy
>>          }
>>
>>          chain system_slice {
>>                  socket cgroupv2 level 2 vmap @dict_cgroup_level_2
>>                  # policy for system.slice process
>>          }
>>
>>          chain input {
>>                  type filter hook input priority filter; policy drop;
> 
> This example should use the output chain instead:
> 
>            chain output {
>                    type filter hook output priority filter; policy drop;
> 
>  From the input chain, the packet relies on early demux to have access
> to the socket.
> 
> The idea would be to filter out outgoing traffic and rely on conntrack
> for (established) input traffic.

Is it really so that 'socket cgroupv2' can't be used on input side at 
all? At least 'ss' can display the cgroup for listening sockets 
correctly, so the cgroup information should be available somewhere:

$ ss -lt --cgroup
State    Recv-Q   Send-Q       Local Address:Port       Peer 
Address:Port   Process 

LISTEN   0        4096                  *%lo:ssh                   *:* 
      cgroup:/system.slice/ssh.socket

-Topi