Apparmor denied

Hi everyone,

I am developing an application for an arm64 platform running ubuntu core. Our application is written in .NET 5. I have created the snap with plugs to: network, network-bind and network-observe.
Everything seems to be working fine (grade is still devel) but the system gets floaded with a lot of apparmor messages:

[2014109.948456] audit: type=1400 audit(1611766047.163:5036913): apparmor="DENIED" operation="file_lock" profile="snap.iotgateway.driverhandler" name="/proc/18837/net/route" pid=18837 comm=2E4E455420546872656164506F6F6C requested_mask="k" denied_mask="k" fsuid=0 ouid=0
[2014109.949342] audit: type=1400 audit(1611766047.163:5036914): apparmor="DENIED" operation="file_lock" profile="snap.iotgateway.driverhandler" name="/proc/18837/net/route" pid=18837 comm=2E4E455420546872656164506F6F6C requested_mask="k" denied_mask="k" fsuid=0 ouid=0
[2014109.949360] audit: type=1400 audit(1611766047.163:5036915): apparmor="DENIED" operation="file_lock" profile="snap.iotgateway.driverhandler" name="/proc/18837/net/ipv6_route" pid=18837 comm=2E4E455420546872656164506F6F6C requested_mask="k" denied_mask="k" fsuid=0 ouid=0
[2014109.949373] audit: type=1400 audit(1611766047.163:5036916): apparmor="DENIED" operation="file_lock" profile="snap.iotgateway.driverhandler" name="/proc/18837/net/ipv6_route" pid=18837 comm=2E4E455420546872656164506F6F6C requested_mask="k" denied_mask="k" fsuid=0 ouid=0
[2014109.954342] audit: type=1400 audit(1611766047.173:5036917): apparmor="DENIED" operation="file_lock" profile="snap.iotgateway.driverhandler" name="/proc/sys/net/ipv4/conf/lo/forwarding" pid=18837 comm=2E4E455420546872656164506F6F6C requested_mask="k" denied_mask="k" fsuid=0 ouid=0
[2014109.954782] audit: type=1400 audit(1611766047.173:5036918): apparmor="DENIED" operation="file_lock" profile="snap.iotgateway.driverhandler" name="/proc/sys/net/ipv4/conf/lo/forwarding" pid=18837 comm=2E4E455420546872656164506F6F6C requested_mask="k" denied_mask="k" fsuid=0 ouid=0
[2014109.955184] audit: type=1400 audit(1611766047.173:5036919): apparmor="DENIED" operation="file_lock" profile="snap.iotgateway.driverhandler" name="/proc/sys/net/ipv4/conf/eth1/forwarding" pid=18837 comm=2E4E455420546872656164506F6F6C requested_mask="k" denied_mask="k" fsuid=0 ouid=0
[2014109.955481] audit: type=1400 audit(1611766047.173:5036920): apparmor="DENIED" operation="file_lock" profile="snap.iotgateway.driverhandler" name="/proc/sys/net/ipv4/conf/eth1/forwarding" pid=18837 comm=2E4E455420546872656164506F6F6C requested_mask="k" denied_mask="k" fsuid=0 ouid=0
[2014109.955856] audit: type=1400 audit(1611766047.173:5036921): apparmor="DENIED" operation="file_lock" profile="snap.iotgateway.driverhandler" name="/proc/sys/net/ipv4/conf/eth0/forwarding" pid=18837 comm=2E4E455420546872656164506F6F6C requested_mask="k" denied_mask="k" fsuid=0 ouid=0
[2014109.956172] audit: type=1400 audit(1611766047.173:5036922): apparmor="DENIED" operation="file_lock" profile="snap.iotgateway.driverhandler" name="/proc/sys/net/ipv4/conf/eth0/forwarding" pid=18837 comm=2E4E455420546872656164506F6F6C requested_mask="k" denied_mask="k" fsuid=0 ouid=0
[2014117.938953] kauditd_printk_skb: 10 callbacks suppressed

The pid is the running pid of our application.
Any suggestions?

install the snappy-debug snap on your system and run the snappy-debug command in a second terminal while running your app.

it should come up with some suggestions of interface plugs to add to your app so the denials go away.

Thank you for the reply. Unfortunately the suggestions it gives me is:
Suggestions:

  • adjust program to not access ‘@{PROC}/sys/net/ipv4/conf/lo/forwarding’
  • adjust program to not access ‘@{PROC}/sys/net/ipv[0-9]*/conf/lo/forwarding’

Is your program some kind of router management utility and needs to inspect the routing table or otherwise know whether traffic is can be forwarded to particular interfaces?

My program translates messages and commands of ip connected devices (eg PA systems, Onvif Cams and so on) to mqtt topics.
It uses nuget packages MqttNet (for mqtt connection on localhost) and ZeroConf for zeroconf device discovery.
For webservice discovery it sends probe messages to 239.255.255.250 about every 30 secs

I still get these apparmor messages, even when nothing else is connected. So I guess the cause should be one of these three mechanisms?

Then you should definitely start with plugging network-observe.

I see that the loopback (lo) device isn’t covered by the AppArmor policy, perhaps we need to adjust it.

1 Like

In my snapcraft.yaml I have “plugs: [network, network-bind, network-observe]”, network-observe is already there.

Node-red (also installed as a snap) is also connected to the mqttbroker via localhost and that doesn’t seem to give any problems/logging

is it also listed as connected in

snap connections iotgateway

(network-observe does not auto-connect)

Yes, it looks like it:
network iotgateway:network :network -
network-bind iotgateway:network-bind :network-bind -
network-observe iotgateway:network-observe :network-observe manual

snapd:master$ grep forward interfaces/builtin/*
interfaces/builtin/firewall_control.go:@{PROC}/sys/net/ipv4/ip_forward w,
interfaces/builtin/firewall_control.go:@{PROC}/sys/net/ipv6/conf/*/forwarding w,

try adding the firewall-control interface (and connect it), that should at least cover the ipv6 denial (not sure why it does not cover ipv4, that probably needs fixing)…

[2014109.954782] audit: type=1400 audit(1611766047.173:5036918): 
apparmor="DENIED" operation="file_lock"
 profile="snap.iotgateway.driverhandler"
 name="/proc/sys/net/ipv4/conf/lo/forwarding" pid=18837 comm=2E4E455420546872656164506F6F6C
 requested_mask="k" denied_mask="k" fsuid=0 ouid=0

It’s really trying to lock those files, our policies only allow reading (network-observe) or writing (firewall-control).

Edit: and none of the policies allows loopback ofc.

1 Like

oops, i missed the file_lock

Perhaps we could extend the policy to allow locking, but I’d like to know the security team’s thoughts about this first, cc @alexmurray

I’ve not come across a process wanting to lock files under /proc - is this a normal thing to want to do? If so, what purpose does it serve? Finally, can the application be changed to just simply not lock these files instead or is this a required piece of functionality?

The application is developed in .NET5. I do not actively try to lock anything. Don’t know how .NET handles and translates network requests/traffic.

If I disable the ZeroConf (nuget) package, most messages seem to have disappeared, well at least the fact that I get these messages every 8 seconds. I did see an occasional apparmor denied on /proc/5944/net/tcp(6). Need to look into this further

I have taken a look at the ZeroConf package. Standard it does a call
netInterfacesToSendRequestOn = System.Net.NetworkInformation.NetworkInterface.GetAllNetworkInterfaces()
and sends an mdns request on every interface.
Could it be that the GetAllInterfaces() call results in the apparmor denied message?

It does this every 4 seconds…

so you could use it as a timer :wink: (SCNR)

Yep that is possible :grin: