[systemd-devel] Portable services

[Umut Tezduyar Lindskog]

On 2021-09-14, 3:43 PM, "Lennart Poettering" <lennart at poettering.net> wrote:

    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:

Thanks for the suggestion. 

    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.

Sounds like a good idea. 

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

Sorry for misusing the term. I have meant "portablectl --extension" option. 

    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.

Interesting to hear. Thanks for your feedback and looking forward to hear from others. 

Umut

    Lennart

    --
    Lennart Poettering, Berlin