Re: [systemd-devel] loose thoughts around portable services
On Mi, 20.10.21 16:01, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: > > 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. I sympathize with the idea, but I am not entirely sure this is desirable to do this 1:1, as this means we'd leak a ton of stuff that might only make sense on the host into something that is supposed to be an isolated container. i.e. home dir info and things like that. shell paths and so on. Maybe we can find a middle ground on this though. i.e. we could make systemd-userdb.service listen on a new varlink service socket that provides the host's database to sandboxed environments in a restricted form, i.e. with basically all records dumbed down to just contain uid/gid/name info and nothing else. We'd then update the portabled profiles that do not use PrivateUsers= to bind mount that one socket, so that they get the full db, dynamically. I kinda like the idea. > 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. A patch adding .d/ style drop-ins for profiles would make a ton of sense. Happy to take that. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] loose thoughts around portable services
Thanks for your reply. On Mon, Oct 18, 2021 at 9:49 AM Lennart Poettering wrote: > On Mi, 13.10.21 13:38, Umut Tezduyar Lindskog (umut.tezdu...@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. htt
Re: [systemd-devel] loose thoughts around portable services
On Mi, 13.10.21 13:38, Umut Tezduyar Lindskog (umut.tezdu...@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
[systemd-devel] loose thoughts around portable services
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? 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. 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. Has there been any thought about nesting profiles? Example, one profile can include other profiles in it. 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. Thank you for your comments Umut
