Comment 2 for bug 1814596

Hello,

The attack scenario seems either the service is malicious or a local attacker was able to exploit a vulnerable service and he is now trying to escape the sandbox enforced by systemd.

It seems to me there are at least 2 flaws in this report:
1) a service can break out of the sandbox enforced by PrivateTmp=true, ProtectSystem=strict and ProtectHome=read-only enforced by systemd (independently of DynamicUser= being used, User= would be the same) by passing file descriptors through UNIX sockets. Indeed it shouldn't be possible for such a service to write/read the real /tmp directory nor to write in paths not specified in ReadWritePaths. The PoC above is able to do this.
2) a service can create a setuid/setgid executable file that can be used to get the temporary service UID even after the service is terminated (thus with all the problems of the UID recycling and accessing resources that may be owned by a completely different service in the future).

I think blocking "chmod()/fchmod() calls with modes that include setuid/setgid bits" is just going to prevent the 2) flaw, but not 1).