当 NoNewPrivileges=no 时,AppArmor 以 "no new privs" 拒绝执行

AppArmor deny execution with "no new privs" when NoNewPrivileges=no

在尝试限制我的 Python 应用程序后,我一直在点击这些 AppArmor 消息

[ 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

使用此配置文件(由 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 是系统服务。阅读此 post 后,我注意到 api.service 确实设置了 NoNewPrivileges=yes。所以我将其更改为 NoNewPrivileges=no(并重新加载了服务),但这并没有改变任何事情。行为仍然完全相同。

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.

知道还有什么会导致 info="no new privs" 吗?

找到了!

https://github.com/systemd/systemd/issues/18914

ProtectHostname=yes appears to imply NoNewPrivileges=yes