Support for ACLs for bridge NIC device when using nftables driver.

[mikerobski]

Allows "security.acls*" fields to be used to apply ACLs to bridge NIC device when the firewall driver is nftables.

Since the nftables do not support "reject" rules, the implementation converts the default rules from "reject" to "drop" when needed.

The ACL rules are applied together with the filtering rules, if specified. The filtering rules are applied before the ACL rules and are enforced even if the ACL definition contains allow rule that permits the traffic.

[stgraber]

Since the nftables do not support "reject" rules, the implementation converts the default rules from "reject" to "drop" when needed.

I'm confused by that comment, nftables does have a reject target, what do you mean by that?

[stgraber]

@mikerobski any chance that you can open PRs from a personal fork?

That would then let me push rebases and tweaks on top of your change to tweak it until it's in shape for merging, avoiding needless back and forth for tiny changes to your PR.

[stgraber]

@mikerobski And sorry for the delay on this one. It's been a bit of a crazy time on my end what between getting married and a whole bunch of travel. I somehow remembered this PR being more complex than it is now, possibly because of a previous version of it. As it stands, this is well structured and pretty minimal so we should be able to get this into shape and merged pretty quick.

It looks like I'll want to do a few small edits to the doc, add an API extension string and some other minor changes, but outside of the drop vs reject thing, this looks well structured and almost good to go.

[mikerobski]

Since the nftables do not support "reject" rules, the implementation converts the default rules from "reject" to "drop" when needed.

I'm confused by that comment, nftables does have a reject target, what do you mean by that?

The ACL rules we add are L2 and reject nft rule is not being accepted for the bridge family.

[stgraber]

The ACL rules we add are L2 and reject nft rule is not being accepted for the bridge family.

Ah, right, makes sense when processed at the L2 level.

[mikerobski]

@mikerobski any chance that you can open PRs from a personal fork?

That would then let me push rebases and tweaks on top of your change to tweak it until it's in shape for merging, avoiding needless back and forth for tiny changes to your PR.

I will look into it, but it may take me some time to figure out.

[stgraber]

Ah, right, makes sense when processed at the L2 level.

stgraber@dakara:~/data/code/lxc/incus (pr1225)$ sudo nft delete rule bridge incus in.u1.eth0 handle 34
stgraber@dakara:~/data/code/lxc/incus (pr1225)$ sudo nft insert rule bridge incus in.u1.eth0 iifname "veth078cc364" ip daddr 1.1.1.1 reject
stgraber@dakara:~/data/code/lxc/incus (pr1225)$ 

This works perfectly fine here and results in the expected:

root@u1:~# ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
From 1.1.1.1 icmp_seq=1 Destination Port Unreachable
From 1.1.1.1 icmp_seq=2 Destination Port Unreachable
^C
--- 1.1.1.1 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1022ms

root@u1:~# 

[mikerobski]

Ah, right, makes sense when processed at the L2 level.

stgraber@dakara:~/data/code/lxc/incus (pr1225)$ sudo nft delete rule bridge incus in.u1.eth0 handle 34
stgraber@dakara:~/data/code/lxc/incus (pr1225)$ sudo nft insert rule bridge incus in.u1.eth0 iifname "veth078cc364" ip daddr 1.1.1.1 reject
stgraber@dakara:~/data/code/lxc/incus (pr1225)$ 

This works perfectly fine here and results in the expected:

root@u1:~# ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
From 1.1.1.1 icmp_seq=1 Destination Port Unreachable
From 1.1.1.1 icmp_seq=2 Destination Port Unreachable
^C
--- 1.1.1.1 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1022ms

root@u1:~# 

While indeed it works for input, it does not work for forward:

table bridge incus {
        chain fwd.vm01.eth0 {
                type filter hook forward priority filter; policy accept;
                ip daddr 1.1.1.1 counter packets 0 bytes 0 drop
                ip daddr 1.1.1.1 counter packets 0 bytes 0 drop
        }

        chain in.vm01.eth0 {
                type filter hook input priority filter; policy accept;
                ip daddr 1.1.1.1 counter packets 0 bytes 0 drop
                ip daddr 1.1.1.1 counter packets 0 bytes 0 reject with icmp port-unreachable
        }
}

nft add rule bridge incus fwd.vm01.eth0 ip daddr 1.1.1.1 counter reject
Error: Could not process rule: Operation not supported
add rule bridge incus fwd.vm01.eth0 ip daddr 1.1.1.1 counter reject
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

It will be confusing to allow the reject rule when it is not supported for the forward chain, right?

[stgraber]

When is the forward table being hit in the bridge case?
Is that for connections between interfaces on the same bridge?

Btw, I just noticed a bit of a problem when testing this branch locally here.
If I create two containers and only apply an ACL to one of them:

egress:
- action: allow
  state: enabled
- action: drop
  destination: 1.1.1.1
  state: enabled
ingress: []

Then both containers can interact with the internet just fine, the container with no ACL applied can interact with all other containers except for the one with the ACL applied. So far that's normal.

What's not normal is that the container with the ACL applied is completely unable to interact with the container which doesn't have the ACL applied even though the restricted container has an rule allowing all egress.

Trying to ping from the container with the ACL to the one without only shows ARP going out and being responded to, no actual ICMP packet, so that'd suggest that the ARP response isn't making it back to the container with the ACL.