<div dir="ltr"><div>Thanks for your reply. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 18, 2021 at 9:49 AM Lennart Poettering <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Mi, 13.10.21 13:38, Umut Tezduyar Lindskog (<a href="mailto:Umut.Tezduyar@axis.com" target="_blank">Umut.Tezduyar@axis.com</a>) wrote:<br>
<br>
> Hi, we have been playing around more with the portable services and<br>
> lots of loose thoughts came up. Hopefully we can initiate<br>
> discussions.<br>
><br>
> The PrivateUsers and DynamicUsers are turned off for the trusted<br>
> profile in portable services but none of the passwd/group and nss<br>
> files are mapped to the sandbox by default essentially preventing<br>
> the sandbox to do a user look up. Is this a use case that should be<br>
> offered by the “trusted” profile or should this be handled by the<br>
> services that would like to do a look-up?<br>
<br>
The "trusted" profile basically means you dealt with that<br>
synchronization yourself in some way.<br>
<br>
That said: systemd's nss-systemd NSS module can nowadays (v249) read<br>
user definitions from drop-in JSON fragments in<br>
/run/host/userdb/. This is is used by nspawn's --bind-user= feature to<br>
make a host user easily available in a container, with group info,<br>
password and so on. My plan was to also make use of this in the unit<br>
executor, i.e. so that whenever RootDirectory=/RootImage= are used the<br>
service manager places such minimal user info for the selected user<br>
there, so that the user is perfectly resolvable inside the service<br>
too. This is particularly relevant for DynamicUser=1 services. I<br>
haven't come around actually implementing that though. Given<br>
nss-systemd is enabled in most bigger distro's nssswitch.conf file<br>
these days I think this is a really nice approach to propagate user<br>
databases like that.<br></blockquote><div><br></div><div>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. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
> Is there a way to have PrivateUsers=yes and map more host users to<br>
> the sandbox? We have dynamic, uid based authorization on dbus<br>
> methods. Up on receiving a method, the server checks the sender uid<br>
> against a set of rule files.<br>
<br>
I guess we could add BindUser= or so, which could control the<br>
/run/host/userdb/ propagation I proposed above.<br>
<br>
> Would it benefit others if the “profile” support was moved out of<br>
> the portable services and be part of the unit files? For example<br>
> part of the [Install] section.<br>
<br>
Right now profiles are a concept of portabled, not of the service<br>
manager. There's a github issue somewhere where people asked us to<br>
make this generically usable from services too, so I guess you are not<br>
the only one who'd like someting like that.<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
> Has there been any thought about nesting profiles? Example, one<br>
> profile can include other profiles in it.<br>
<br>
File an RFE issue. I guess we could support that for any profile x<br>
we'd implicitly also pull in x.d/*.conf, or so.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
> Systemd analyze security is great! We believe it would be easier to<br>
> audit if we had a way to compare a service file’s sandboxing<br>
> directives against a profile and find the delta. Then score the<br>
> service file against delta.<br>
<br>
Interesting idea.<br>
<br>
Current git has all kinds of JSON hookup for systemd-analyze security<br>
btw, so tools could do that externally too. But you are right, doing<br>
this implicitly might indeed make sense. Please file an RFE issue on<br>
github.<br></blockquote><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div><a href="https://github.com/systemd/systemd/issues/21067">https://github.com/systemd/systemd/issues/21067</a><br></div><div><br></div><div>Thanks,</div><div>Umut</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
Lennart<br>
<br>
--<br>
Lennart Poettering, Berlin<br>
</blockquote></div></div>