[systemd-devel] loose thoughts around portable services

Wed Oct 20 14:01:42 UTC 2021

Thanks for your reply.

On Mon, Oct 18, 2021 at 9:49 AM Lennart Poettering <lennart at poettering.net>
wrote:

> 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.
>

Why don't we also make the varlink user API available to most of the
profiles? This way sandboxed service doesn't need any of the nss conf and
libraries if they don't want to. Most profiles allow dbus communication. I
guess in a similar thought, most system services should be able to do a
user lookup in a modern way.

>
> > 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.
>

One important thing that would be missed in that case is the RootDirectory,
RootImage which is I think is important to restrict the file system.

> > 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.
>

We could implement our own profiles without needing nesting but we believe
it is beneficial to collaborate on profiles upstream and have common
additions to upstream profiles with nesting other profiles. If we get to it
before other people, we would really like to contribute and send a patch on
this.

>
> > 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.
>

So the background is that we have many different domain experts but only
few systemd domain experts. Even less systemd sandboxing experts. We could
ask the systemd sandboxing experts to go through 50+ services and make sure
they apply the "least privilege principle" however A) This would be a one
time change and it would miss all newly implemented services. B) These
experts are not experts in other domains. It would be hard for them to
figure out what needs to be closed/opened.

Another idea we had was to use the default configuration settings but
turned out to be complex task to make the changes on the service files due
to the diversity of services, effort it takes to educate the domain
experts.

Therefore we are interested in profiles. Systemd sandboxing domain experts
set profiles, other domain experts pick a profile and figure out what needs
to be opened up on top of the profile. We don't want them to be opened up
more than the "least privilege principle" therefore we want to audit the
opened up parts as a delta.

https://github.com/systemd/systemd/issues/21067

Thanks,
Umut

>
> Lennart
>
> --
> Lennart Poettering, Berlin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20211020/6f5a47c2/attachment.htm>