[systemd-devel] Starting transient services securely from other service without root

Michal Koutný mkoutny at suse.com
Wed Apr 27 15:48:45 UTC 2022


Hello Vašek.

On Mon, Apr 25, 2022 at 10:45:34AM +0200, Vašek Šraier <vaclav.sraier at nic.cz> wrote:
> TL;DR: I want to start transient system services from another system
> service via DBus. All services should have as little privileges as
> possible, definitely not root. How can I do that securely?

PolicyKit popped to my mind with this short description, basically what
you extend later.
(Also I understand the "starter" and "started" are both the same user.)


> Because the workers are slightly different (e.g. command line args) and
> because it could be confusing to admins, we decided to use transient
> services so that the workers can't be started without the master
> process.

Note this may be also capture with scopes (if you decide to track
lifecycle of workers yourself instead of by systemd). But also scopes
within PID1 require privileges, so that just redresses your problem.


> - User sessions
>   The master process and worker processes can also run in a user 
>   session. This directly solves problems with privileges. However, I am
>   not sure if running a user session with the semantics of a system
>   service is possible or a good idea. I also don't know if there is any
>   documentation related to user sessions without physical users.

Do you mean having all your stuff as services of user instance of
systemd?
Or putting them in proper sessions (as PAMName=foo does)?
I assume the former. It sounds also a bit strange (unusual use of user
instance of unusual(?) requirements).
One consequence that I see directly is that any resource assigned via
cgroups would be restricted by the single user instance for the whole
assemply of workers together. (That can be intended or not.)

(For the latter, I wrote it just for completeness, I don't think it'd be
useful in this case.)

> - Use other service managers, not systemd

Or minimize functions of your main process to just process the config
and figure out jobs so that it can run as root with anything "sensitive"
(open to external world) moved to unprivileged workers/helpers.

In the end, I think it goes along axes like:
- Is there any benefit of having the workers in individual systemd
  units? (That suggests just controlling everything by the main process
  (or 3rd party supervisor.)

- Is there any privilege that is actually needed from PID1 or could a
  given user self-serve themselves? (That suggest the user instance
  services below.)

HTH,
Michal


More information about the systemd-devel mailing list