enterprise-support team mailing list archive

[Dan Streetman <1934393@xxxxxxxxxxxxxxxxxx>]

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
Server/Client Support Team, which is subscribed to openldap in Ubuntu.
Matching subscriptions: Ubuntu Server/Client Support Team
https://bugs.launchpad.net/bugs/1934393

Title:
  systemd-logind network access is blocked, and breaks remote
  authentication configurations

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1934393/+subscriptions