Re: capabilities for systemd --user

[Lennart Poettering <mzerqung@xxxxxxxxxxx>]

On Mo, 27.06.22 23:36, Lukasz Stelmach (l.stelmach@xxxxxxxxxxx) wrote:

> Hi,
>
> I need an apparently exotic configuration and I don't know how to
> approach the problem. Here are the requirements:
>
> - user@1234.service (systemd --user)
>   + runs with Priv SMACK label (SmackProcessLabel in user@.service)
>   + has cap_mac_admin (and a few other capabilities) to assign SMACK
>     labels to its children (AmbientCapabilities in user@.service)
>
> - children (session services) run with Reg SMACK label (I added
>   support for DefaultSmackProcessLabel to user.conf, to avoid
>   modifications of all unit files)

sounds upstreamable.

>
> - children DO NOT inherit capabilites from systemd --user (they do now)
>
> This last is a problem because I'd like to avoid modifications of all
> service files. I tried to drop inheritable caps before execve() (in
> exec_child()) but as described in capabilities(7) this results in
> dropping caps from the ambient set too, which means systemd --user
> doens't get what it needs.
>
> Is there anything I am missing? Is there any way to start a service with
> UID!=0, some capabilities set but not implicitly inheritable by
> processes spawned by the service?

Quite frankly that should probably be the default behaviour.

I'd probably merge a patch that unconditionally resets all caps
passed to children of the --user manager even if the manager itself
got some ambient caps passed. It might be a slight compat breakage,
but I think it would be safer that way, as the service execution
environment becomes more uniform then.

Security credentials should be passed down to user services opt-in,
not opt-out after all.

Can you prep a patch for that and submit via github?

Lennart

--
Lennart Poettering, Berlin