One good point in favor of including systemd-userdbd in Debian/Ubuntu would be that we only need to adjust the restrictions for that service; all other systemd-provided services would use (or at least, *should* use...) systemd-userdbd to get user records. I'm not sure if that is actually worth including and using systemd-userdbd to the distro.
Putting that aside for now, I think the only options to fix this all involve removing the systemd-logind restriction(s). The only question seems to be what/who removes the restrictions. 1) We could simply remove the restrictions for systemd-logind in the Debian/Ubuntu package, for everyone. This would (theoretically) reduce the security of systemd-logind by allowing it to access the network, but also it would allow network-based NSS lookups to work in all situations (meaning, for all possible NSS modules, not only NIS and/or select other packages/modules). 2) We could add drop-in files to remove the restrictions for systemd- logind, for the 'nis' package (which I think has been split out in later releases and in Debian, so we'd need to pick the correct client package). We would also need to include drop-in files for any other package that provides an NSS module that needs to perform network lookups, such as the 'libnss-ldap' package (I haven't verified this needs network access but I believe it does, e.g. comment 7 above). 3) We could simply add documentation to the README and/or man pages and/or other docs and leave it up to the system admin to add the systemd-logind drop-in file when they set up NIS or LDAP or whatever other network-based auth provider. Personally, I think #3 is barely better than the current situation; there's just far too many setup guides and other documentation out there for us to expect all Debian/Ubuntu users to notice the additional step we might add to our own docs, even if it's in the package README and man pages. However, if we think that NSS-based network auth services are a thing of the past (as seems to be the upstream position on this), then maybe just adding docs is the right way to handle this. I'm not too enthusiastic about option #2 either. While it would help with users of specific packages, without those users needing to know any specific details about the workaround, it won't cover all use cases - since we don't necessarily know all the different packages that might need to provide a drop-in - and also it could *add* confusion in some cases. For example, if someone is using a custom network-based libnss module, it would work on any system where they had the 'nis' package installed, but fail on any system where it wasn't installed - regardless of whether they are actually using nis for anything at all. That's the kind of thing that is incredibly painful to debug. This option also would require the 'nis' and 'libnss-ldap' packages to restart systemd- logind when they are installed, which (in the past at least) has sometimes been problematic. I know that option #1 is kind of the 'worst', since it essentially just gives up and removes the restriction from systemd-logind for everyone. However, I personally think it's the best option. If/when we do start providing systemd-userdbd (and it's enabled by default), I think we should move the lifted restriction over to it, instead of systemd- logind. But for now we should just modify systemd-logind to allow network access, IMHO. Since this is *theoretically* related to security, I'd like to get the Ubuntu security team's opinion on the change. I've cc'ed them on this bug. @mbiebl, what do you think? I really don't know what the best approach is, either for Debian or for Ubuntu. And obviously, if you (or anyone) has other suggestions I'm happy to hear them. And finally just FTR, I personally think upstream systemd should just remove the restriction (specifically, I mean remove IPAddressDeny=any) from systemd-userdbd.service. That service already funnels all systemd requests for user data into a single isolated process, I think it's overkill to also restrict that process from network access, when it's so common to have NSS-based network authentication mechanisms. However, Lennart's made his opinion known[1], and I'd prefer not to be the person who tries to argue with him to change his mind. [1]: https://github.com/systemd/systemd/issues/15705#issuecomment-624125354 ** Changed in: systemd (Ubuntu) Status: Won't Fix => Confirmed ** Description changed: [impact] starting in focal, systemd-logind runs sandboxed without any network access, which breaks any configuration that uses remote servers for user data, e.g. ldap, nis, etc A more full discussion is available in the upstream bug report as well as the debian bug report, see other info section below [test case] many possible ways to reproduce this; there are reproducers in some of the bugs reported before that are caused by this, e.g. bug 1915502 or bug 1916235 [regression potential] failure to authenticate when using remote user data, incorrect authentication, security issues due to un-sandboxing of systemd-logind [scope] this is needed in f and later before focal, systemd-logind was not sandboxed so this did not apply [other info] this isn't actually a bug in systemd, this is a by-design security feature; see links below (and/or comment 13 in this bug) to upstream comments about how systemd's position is that no NSS module should ever perform network access, and any NSS module that does needs to also adjust the restrictions of systemd services such as systemd-logind, systemd-userdbd, and possibly others that might need to make NSS calls into glibc. https://github.com/systemd/systemd/issues/7074#issuecomment-338157851 https://github.com/systemd/systemd/issues/15705#issuecomment-624125354 this may also can cause systemd-udevd failures in some cases as well. https://github.com/systemd/systemd/pull/7343#issuecomment-344800313 For reference, upstream discussion around the systemd-logind sandboxing specifically: https://github.com/systemd/systemd/issues/7074 upstream updated doc PR explaining the upstream position: https://github.com/systemd/systemd/pull/7343 Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878625 + Note that while this Debian bug is marked as fix released, I don't think it actually fixes the problem, from the final comment it seems like the only change was to add Recommends: nscd, which doesn't really solve things if someone doesn't use nscd. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1934393 Title: systemd-logind network access is blocked, and breaks remote authentication configurations Status in systemd: Fix Released Status in nis package in Ubuntu: Confirmed Status in openldap package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in nis package in Debian: Fix Released Bug description: [impact] starting in focal, systemd-logind runs sandboxed without any network access, which breaks any configuration that uses remote servers for user data, e.g. ldap, nis, etc A more full discussion is available in the upstream bug report as well as the debian bug report, see other info section below [test case] many possible ways to reproduce this; there are reproducers in some of the bugs reported before that are caused by this, e.g. bug 1915502 or bug 1916235 [regression potential] failure to authenticate when using remote user data, incorrect authentication, security issues due to un-sandboxing of systemd-logind [scope] this is needed in f and later before focal, systemd-logind was not sandboxed so this did not apply [other info] this isn't actually a bug in systemd, this is a by-design security feature; see links below (and/or comment 13 in this bug) to upstream comments about how systemd's position is that no NSS module should ever perform network access, and any NSS module that does needs to also adjust the restrictions of systemd services such as systemd-logind, systemd-userdbd, and possibly others that might need to make NSS calls into glibc. https://github.com/systemd/systemd/issues/7074#issuecomment-338157851 https://github.com/systemd/systemd/issues/15705#issuecomment-624125354 this may also can cause systemd-udevd failures in some cases as well. https://github.com/systemd/systemd/pull/7343#issuecomment-344800313 For reference, upstream discussion around the systemd-logind sandboxing specifically: https://github.com/systemd/systemd/issues/7074 upstream updated doc PR explaining the upstream position: https://github.com/systemd/systemd/pull/7343 Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878625 Note that while this Debian bug is marked as fix released, I don't think it actually fixes the problem, from the final comment it seems like the only change was to add Recommends: nscd, which doesn't really solve things if someone doesn't use nscd. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1934393/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
