[systemd-devel] loose thoughts around portable services

[Lennart Poettering]

On Mi, 13.10.21 13:38, Umut Tezduyar Lindskog (Umut.Tezduyar at axis.com) wrote:

> Hi, we have been playing around more with the portable services and
> lots of loose thoughts came up. Hopefully we can initiate
> discussions.
>
> The PrivateUsers and DynamicUsers are turned off for the trusted
> profile in portable services but none of the passwd/group and nss
> files are mapped to the sandbox by default essentially preventing
> the sandbox to do a user look up. Is this a use case that should be
> offered by the “trusted” profile or should this be handled by the
> services that would like to do a look-up?

The "trusted" profile basically means you dealt with that
synchronization yourself in some way.

That said: systemd's nss-systemd NSS module can nowadays (v249) read
user definitions from drop-in JSON fragments in
/run/host/userdb/. This is is used by nspawn's --bind-user= feature to
make a host user easily available in a container, with group info,
password and so on. My plan was to also make use of this in the unit
executor, i.e. so that whenever RootDirectory=/RootImage= are used the
service manager places such minimal user info for the selected user
there, so that the user is perfectly resolvable inside the service
too. This is particularly relevant for DynamicUser=1 services. I
haven't come around actually implementing that though. Given
nss-systemd is enabled in most bigger distro's nssswitch.conf file
these days I think this is a really nice approach to propagate user
databases like that.

> Is there a way to have PrivateUsers=yes and map more host users to
> the sandbox? We have dynamic, uid based authorization on dbus
> methods. Up on receiving a method, the server checks the sender uid
> against a set of rule files.

I guess we could add BindUser= or so, which could control the
/run/host/userdb/ propagation I proposed above.

> Would it benefit others if the “profile” support was moved out of
> the portable services and be part of the unit files? For example
> part of the [Install] section.

Right now profiles are a concept of portabled, not of the service
manager. There's a github issue somewhere where people asked us to
make this generically usable from services too, so I guess you are not
the only one who'd like someting like that.

> Has there been any thought about nesting profiles? Example, one
> profile can include other profiles in it.

File an RFE issue. I guess we could support that for any profile x
we'd implicitly also pull in x.d/*.conf, or so.

> Systemd analyze security is great! We believe it would be easier to
> audit if we had a way to compare a service file’s sandboxing
> directives against a profile and find the delta. Then score the
> service file against delta.

Interesting idea.

Current git has all kinds of JSON hookup for systemd-analyze security
btw, so tools could do that externally too. But you are right, doing
this implicitly might indeed make sense. Please file an RFE issue on
github.

Lennart

--
Lennart Poettering, Berlin