Denial for file_lock on /run/netns while using network-control interface

[Berkay Tekin Öz]

The K8s team is implementing Cilium support under strict confinement. Cilium utilizes network namespaces and is faced with an apparmor denial even when using the network-control interface. Manually adding the "k" mask for "/run/netns" by editing the profile generated by snapd gets rid of the denial, and is used as a workaround currently.

= AppArmor =
Time: 2023-11-29T13:1
Log: apparmor="DENIED" operation="file_lock" class="file" profile="snap.k8s.containerd" name="/run/netns/" pid=20134 comm="ip" requested_mask="k" denied_mask="k" fsuid=0 ouid=0
File: /run/netns/ (write)

Versions
snap 2.60.4+23.10.1
snapd 2.60.4+23.10.1
series 16
ubuntu 23.10
kernel 6.5.0-14-generic

[Samuele Pedroni (pedronis)]

is it really trying to lock the entire dir? not just a file inside?

[Berkay Tekin Öz (berkayoz)]

Yes, it seems so as this is the only denial we get. We have not faced any other denials for sub-paths it's always on `/run/netns`. I kind of recall trying to add `k` flag to the network-control interface as `/run/netns/* rwk,` still ending up in a denial(re-checked).

[Maciej Borzecki (maciek-borzecki)]

It seems to the be the 'protocol' ip implements internally: https://github.com/iproute2/iproute2/blob/f22c49730c3691c25a1147081363eb35aa9d1048/ip/ipnetns.c#L819 which results in a failure in some specific scenarios (when trying to make /run/netns a shared mount point).

[Samuele Pedroni (pedronis)]

I opened https://github.com/snapcore/snapd/pull/13500 for this

[Samuele Pedroni (pedronis)]

landed this, the fix will be in the next edge snapd

[Berkay Tekin Öz (berkayoz)]

Tested on edge with

snapd 2.61.1+git1780.g0c2bbfe 21161 latest/edge

and the issue seems to be resolved, we don't face the denial anymore. Thanks a lot!