Comment 3 for bug 1814596

> 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.

Yes, exactly.

> 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.

I disagree. This, in itself, is working normally. If you pass
a file descriptor to some file, the recipient can use the
file descriptor just like the sender could; and if you pass
a file descriptor to a directory, the recipient gains the
ability to look up surrounding paths.

I think the difference here is that I expect systemd's
controls on this to be enforced in a way that is kind of
like DAC - systemd prevents the service from directly
accessing the filesystem, but allows it to gain access if
that access is granted by another process with access -
while you expect Mandatory Access Control that can not be
overridden by other unprivileged userspace processes.

> 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).

Yes. (But note that I pointed out that setgid files can
also be created by processes that don't belong to the
service if the service has set up a namespace's GID map
appropriately.)

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

(Actually, in case someone's going to turn this into a
syscall list, I think you'd want to filter all the
following syscalls: open(), openat(), creat(), chmod(),
fchmod(), fchmodat().)

Yes, blocking such syscalls will block most of the
setuid/setgid creation problem, and it won't prevent
accessing the filesystem through directory FDs that have
been received over unix sockets. But I don't think that's
a problem. If someone sends you a directory FD over a
unix socket, they're just giving you access that is
mostly equivalent to what you'd get if that service
offered APIs for reading and writing arbitrary files
(except that your ephemeral service doesn't have
special access to anything, whereas the service or user
giving you the FD might).