Request for system-files for nftables

nftables-pk is my package of nftables Linux firewall management tools. As a low-level network management utility it requires the following plugs, preferably auto-connected:

  • network-control
  • firewall-control

In addition, to be able to serve as a drop-in replacement for native nftables packages it also requires read-only access to /etc/nftables, thus plug system-files.

The main motivation for creating this package is that the native nftables package in LTS Linux distributions is hopelessly old and has has many bugs so snaps create a convenient alternative to have the latest package installed on the server.

This is almost certainly better done via a snap layout since there is no guarantee the /etc/nftables on the host is compatible with the nftables in the snap. Eg:

layout:
  /etc/nftables:
    bind: $SNAP/etc/nftables

See Snap layouts for details. If you need /etc/nftables from the host, please describe why it is needed instead of a layout.

1 Like

firewall-control is obvious for auto-connection, but why does network-control need to be connected? Can you try plugging and connecting firewall-control and then test your snap and provide the policy violations from journalctl?

why does network-control need to be connected

@jdstrand
network-control is also required as it’s using some kind of netlink interface to control the tables and throwing the following access errors without it (and does not work):

Jul 02 10:58:51 pax audit[8715]: AVC apparmor="DENIED" operation="open" profile="snap.nftables-pk.nft" name="/etc/iproute2/rt_realms" pid=8715 comm="nft" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jul 02 10:58:51 pax audit[8715]: AVC apparmor="DENIED" operation="open" profile="snap.nftables-pk.nft" name="/etc/iproute2/group" pid=8715 comm="nft" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jul 02 10:58:51 pax audit[8715]: AVC apparmor="DENIED" operation="open" profile="snap.nftables-pk.nft" name="/etc/iproute2/rt_realms" pid=8715 comm="nft" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

This is almost certainly better done via a snap layout

Thanks, didn’t even realize this exists! Just switched the snap to layouts and it seems to work like a charm.

@reviewers I got no response since July - can network-control now be connected automatically for this snap? And firewall-control too as discussed above. I believe I provided all required rationale for both. Currently the package is left in half-working state unless I connect network-control manually…

Sorry for the delay on this; I wanted to investigate why this was needed. I can confirm that read-only access is needed for /etc/iproute2/rt_realms and /etc/iproute2/rt_marks for nft’s routing expressions and /etc/iproute2/group for reference a device group. I’ll update the firewall-control interface for these.

With these accesses, the snap seems to operate fine (I was able to add a table, a couple chains and a rule without any denials).

As such, +1 to auto-connect firewall-control, -1 to auto-connect network-control. snapd 2.41 will have the updates to firewall-control.

@reviewers - can others vote on this?

FYI, https://github.com/snapcore/snapd/pull/7235

If as Jamie said, firewall-control with those additions is enough, a +1 for auto-connecting that; and -1 to network-control since it won’t be necessary anymore (IIUC).

Cheers,

  • Daniel

Excellent, thank you - this makes perfect sense.

your snap can use assumes: snapd2.41 as a guardrail against people trying it in older versions.

2 Likes

2 votes for, 0 against auto-connection of firewall-control

0 votes for, 2 against auto-connection of network-control

Granting auto-connection of firewall-control. This is now live.