After trying to confine my Python application I've been hitting these AppArmor messages
[ 1808.635237] audit: type=1400 audit(1600600443.250:50): apparmor="DENIED" operation="exec"
info="no new privs" error=-1 profile="/var/www/localhost/fastcgi/api.py"
name="/usr/bin/python3" pid=5672 comm="api" requested_mask="x" denied_mask="x" fsuid=42 ouid=0
With this profile (generated by aa-logprog)
#include <tunables/global>
profile /var/www/localhost/fastcgi/api.py flags=(attach_disconnected) {
#include <abstractions/base>
# Python:
/usr/bin/python3{,.[7-9]} Cx,
^/usr/bin/python3{,.[7-9]} flags=(attach_disconnected) {
#include <abstractions/base>
/usr/bin/python3{,.[7-9]} mr,
}
}
Api is systemd service. After reading this post i noticed that api.service really has NoNewPrivileges=yes set. So I changed it to NoNewPrivileges=no (and reloaded the service) but that did not change a thing. The behavior is still exactly the same.
yes once a task is under no new privs it is not allowed change its profile and potentially increase its privileges. There is one exception which is the unconfined state, since any profile transition is a reduction of privileges. So you are left with two potential transitions at the moment ix (inherit the current confinement) and stacking. Stacking is probably not what you want in that it keeps the current confinement and adds additional restrictions on top.
Any idea what else can cause info="no new privs"?
Found it!
https://github.com/systemd/systemd/issues/18914
ProtectHostname=yes appears to imply NoNewPrivileges=yes