[systemd-devel] Portable services

[Lennart Poettering]

On Di, 14.09.21 12:10, Umut Tezduyar Lindskog (Umut.Tezduyar at axis.com) wrote:

> Hello,
>
> We, at Axis, have a monolithic operating system backed by a
> platform. There are teams behind the services making up the
> operating system and we have quite many services. We have been
> investigating sandboxing these services and of course systemd
> sandboxing directives are a way to go. Problem is that it is not
> realistic for us to expect teams to be on top of the directives and
> apply the right ones they need (and keep them updated). There shines
> the portable services for us with it’s “profiles”. We are trying to
> sandbox these services while giving them some host access. There
> shined for example how the default profile is set up by giving dbus
> access (binding dbus system socket to a portable service). We would
> like to create a base runtime and expect services to use the base
> runtime, still giving them the option of overriding the
> runtime. There shined the stackable services with latest “extension”
> support. All and all it fits our use case very well.
>
> I am aware that portable services is still enhancing but who out
> there is using it and I am curious about their use case. (Sorry,
> couldn’t wait for spring in Berlin).

The commit history to that dir might give you hint which companies use
it:

https://github.com/systemd/systemd/commits/main/src/portable

But of course, that's only the ones which use it *and* contribute to
it. I am pretty sure there are others which use it, but don't
contribute.

> Seems like DynamicUsers is part of the default profile and
> DynamicUsers is a good thing. Seems like systemd creates a username
> as the same name as the portable service. Does it work with username
> based dbus policies? Is it that we need to be very careful regarding
> who can start a portable service in case they re-use service name to
> go around dbus rules (vs who can edit /etc/passwd).

So, providing D-Bus services from DynamicUser= services is messy. The two
D-Bus brokers out there want to resolve user names at the time they
load policy, and that of course conflicts with the DynamicUser=
concept to some level, since loading policy happens at early boot but
the whole point of DynamicUser= is that these users only appear the
moment the service starts.

The opposite, i.e. connecting as a client to D-Bus services from
DynamicUser= should be OK (it just means you need to be able to
connect to the D-Bus system socket from the service, i.e. you need to
bind mount that socket) — as long as your client is just a regular
client, i.e. doesn't need specific broker-side policy. Thankfully
clients that require installation of specific D-Bus policies is the
exception.

D-Bus progress is currently a bit stuck. Ideally D-Bus maintainers
would provide us with a way how we could marry socket activation and
D-Bus a bit (in the sense, that systemd passes a pre-connected D-Bus
socket to services, for example, and also uploads policy at that
moment). But I wouldn't hold my breath this happens anytime soon.

Note that portable services and system extensions are two different
things.

Regarding system extensions: at RH we are working on using them as a
way to build fully trusted initrds at the moment. background: it's
currently a major shortcoming of generic Linux distros that initrds
are entirely unprotected cryptographically, anyone can modify them at
will without this being detectable, making FDE pretty weak
conceptually; SecureBoot only covers the kernel, but once the initrd
is run all safety is off. I recently pushed a PR that adds embedded
offline-safe PKCS#7 signature support to the disk image logic that
system extensions and portable services build on (and nspawn, …). With
that you get really nice security properties, as we reinvent initrds
in secure, trusted way: the basic initrd is now built into the kernel
(and thus validated along with it), and exotic storage is then added
in via trusted, verifiable system extensions.

Lennart

--
Lennart Poettering, Berlin