Comment 3 for bug 1797194

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