[Bug 1934393] Re: systemd-logind network access is blocked, and breaks remote authentication configurations

[Dan Streetman]

Just to summarize the specific flow of this bug:

1. an application is started for a user session, e.g. sshd handles a user connecting.
2. the application uses pam for authentication, which by default includes pam_systemd as an (optional) module.
3. pam invokes pam_systemd as part of session creation.
4. pam_systemd calls into systemd-logind, over dbus with CreateSession.
5. the running systemd-logind process receives the dbus request and begins setting up the session.
6. systemd-logind attempts to get the full user info via NSS, e.g. getpwuid_r() or similar call
7. glibc attempts the user lookup, doesn't find the UID or username in /etc/passwd using the normal "files" based lookup
8. since nsswitch.conf is configured with network-based authentication (an essential part of this bug), glibc attempts (either through its "compat" mechanism, or separate nss module like libnss_ldap) to open a network connection to the remote authentication server to get the user info
9. since the glibc code, as well as any libnss module loaded by glibc, is running under the systemd-logind process, the network connection fails due to systemd-logind RestrictAddressFamilies= setting
10. nss returns a result of "no user found" to systemd-logind
11. systemd-logind determines it was unable to find the user data for the requested session, so it returns failure over dbus to the pam_systemd module
12. the pam_systemd module returns failure, but since it's marked "optional" (by default) in the pam common-session config file, the application isn't stopped from finishing successful auth
13. the application finishes pam authentication and opens a shell, but without a successful systemd-logind session


note that if there is a local caching component to whatever network authentication is configured - e.g. nscd - glibc might attempt to check that locally first, and if the user is located and no remote connection is needed, the lookup will succeed.

also note that this bug only applies for nss modules that actually
perform network connections directly from the nss module; if the nss
module calls a local unix socket into a separate locally running
process, that won't be blocked, since systemd-logind is allowed to do
AF_UNIX.

As has been pointed out and discussed, it really doesn't seem like there
are any options to address this other than 1) open up systemd-logind to
AF_INET and/or AF_INET6, or 2) provide systemd-logind with a way to
perform nss lookups outside of direct nss calls, e.g. userdb.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd 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:
  Won't Fix
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, and the intended upstream design is for systemd-logind to
  talk to systemd-userdb, so that systemd-logind can remain network-
  sandboxed while systemd-userdb performs any needed network access for
  user/auth data. However, Debian and Ubuntu don't enable/provide
  systemd-userdb, so that design does not work for Debian/Ubuntu.

  this also can cause systemd-udevd failures in some cases as well,
  apparently (based on upstream and debian discussion comments)

  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

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