[systemd-devel] Design patterns for privilege separating systemd services?

[Colin Walters]

On Thu, Feb 18, 2021, at 4:33 PM, Lennart Poettering wrote:

> 1. So we have another RFE which I am very sympathetic to which is to
>    add an Open= setting to service unit files, which could be used to
>    open any kind of file at activation time and pass it via our usual
>    socket activation fd passing protocol over. (Usecase for that was
>    giving access to privileged files to unprivileged processes)

Yes, this is definitely related.

> The above sounds simple enough, no?

Yep!  That sounds fine, and generalizes beyond a 1-1 unit relationship which is definitely better.

> Of course, there's one thing missing still: as I understand you'd
> prefer a socketpair() (i.e. connected socket), instead of a listening
> one to be passed to both sides. But that would be an easy extension,
> i.e. add ListenStream=socketpair or so as another value, which would
> then do the right thing.

The thing I mainly like about socketpair() is that I know it's *only* accessible via the fd - it's https://en.wikipedia.org/wiki/Capability-based_security - except Linux has kind of broken that by creating /proc/N/fd anyways.  So relying on unlinking the socket seems fine, it's easy code to write and verify.

Basically the above Open=@myserver.socket SGTM!

Did you have any thoughts on the the least-bad hack to do for this w/current systemd?  If the unprivileged unit is using a statically allocated user, the least bad hack I can think of is like a:

unpriv.service
```
[Service]
ExecStartPre=+/usr/bin/setfacl -m u:unpriv:rw /run/privservice.socket
```

Where `privservice.socket` defaults to root:root/0600 - globally reachable but not accessible at least.

But I can't think of any way to do this with DynamicUser=yes today without something like the first-class systemd support above.