[network-manager] apparmor denails occur when using dbus api

The ptrace denials are a known issue, and were in fact noted as harmless in bug #1602383. We've done a code inspection of NetworkManager itself, and found no usage of ptrace. Likewise an informal review of all NM dependencies was done, and the offending code wasn't located. This was also re-visited recently during development of the NM 1.10 snap, and the only usage of ptrace found in any of NM's dependencies was in libc6 itself, so ptrace may being called indirectly via libc6.

I've set the priority to Medium as there've been no functional side-effects observed due to these denials to-date.

Unfortunately, while they are harmless from a system perspective, they do cause nuisance log messages.

While this is not so bad itself, it does mean that our customers see them and think there is a problem. In general, app armor denials are not great. Their confusion at these messages requires us to craft additional explanations and reduces their confidence.

Would it make sense to simply give network manager the permissions it needs to perform the `ptrace` operation until the root of the issue is discovered?

I have taken a shot at this one. The root reason for the denials is not really calling ptrace, but accessing the /proc/<pid>/stat file from the process that calls NM using the DBus interface (see [1] for more information). This apparmor denial is triggered only when the caller process uid is root, for instance 'sudo nmcli' triggers the denial while 'nmcli' does not.

What apparmor does is to deny access to some parts of the 'stat' file that contains addresses internal to the process. But NM just wants to read the process start time, for some security related checks (polkit), and in fact the 'read' syscalls that NM executed finish successfully, just filling with 0s the sensitive addresses.

In summary, NM does not need ptrace permissions at all to work correctly and the denials are harmless, but at the same time we cannot avoid them. The solution is to silence them, and in fact the network-manager interface had already a 'deny ptrace' entry, but unfortunately it was not in the right place. This should be solved by this MP:

https://github.com/snapcore/snapd/pull/6975

[1] https://gitlab.com/apparmor/apparmor/wikis/TechnicalDoc_Proc_and_ptrace