1. 14 Aug, 2020 2 commits
  2. 02 Jul, 2020 5 commits
    • Simon McVittie's avatar
      v1.12.20 · ab888117
      Simon McVittie authored
      
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      ab888117
    • Simon McVittie's avatar
      Update NEWS · 5757fd54
      Simon McVittie authored
      
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      5757fd54
    • Simon McVittie's avatar
      userdb: Reference-count DBusUserInfo, DBusGroupInfo · f3b2574f
      Simon McVittie authored
      Previously, the hash table indexed by uid (or gid) took ownership of the
      single reference to the heap-allocated struct, and the hash table
      indexed by username (or group name) had a borrowed pointer to the same
      struct that exists in the other hash table.
      
      However, this can break down if you have two or more distinct usernames
      that share a numeric identifier. This is generally a bad idea, because
      the user-space model in such situations does not match the kernel-space
      reality, and in particular there is no effective kernel-level security
      boundary between such users, but it is sometimes done anyway.
      
      In this case, when the second username is looked up in the userdb, it
      overwrites (replaces) the entry in the hash table that is indexed by
      uid, freeing the DBusUserInfo. This results in both the key and the
      value in the hash table that is indexed by username becoming dangling
      pointers (use-after-free), leading to undefined behaviour, which is
      certainly not what ...
      f3b2574f
    • Simon McVittie's avatar
      userdb: Make lookups return a const pointer · 37b36d49
      Simon McVittie authored
      
      
      This makes it more obvious that the returned pointer points to a
      struct owned by the userdb, which must not be freed or have its
      contents modified, and is only valid to dereference until the next
      modification to the userdb's underlying hash tables (which in practice
      means until the lock is released, because after that we have no
      guarantees about what might be going on in another thread).
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      (cherry picked from commit 6ee66ff7)
      37b36d49
    • Andy Fiddaman's avatar
      Solaris and derivatives do not adjust cmsg_len on MSG_CTRUNC · 732284d5
      Andy Fiddaman authored
      (cherry picked from commit b96ef23e)
      732284d5
  3. 02 Jun, 2020 4 commits
  4. 15 May, 2020 2 commits
  5. 20 Apr, 2020 6 commits
  6. 25 Feb, 2020 2 commits
  7. 20 Feb, 2020 2 commits
  8. 11 Jun, 2019 1 commit
  9. 09 Jun, 2019 3 commits
    • Simon McVittie's avatar
      Prepare version 1.12.16 · 23cc709d
      Simon McVittie authored
      
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      23cc709d
    • Simon McVittie's avatar
      test: Add basic test coverage for DBUS_COOKIE_SHA1 · 066aea77
      Simon McVittie authored
      We don't actually complete successful authentication, because that
      would require us to generate a cookie and compute the correct SHA1,
      which is difficult to do in a deterministic authentication script.
      However, we do assert that #269
      
       (CVE-2019-12749) has been fixed.
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      066aea77
    • Simon McVittie's avatar
      auth: Reject DBUS_COOKIE_SHA1 for users other than the server owner · 47b1a4c4
      Simon McVittie authored
      The DBUS_COOKIE_SHA1 authentication mechanism aims to prove ownership
      of a shared home directory by having the server write a secret "cookie"
      into a .dbus-keyrings subdirectory of the desired identity's home
      directory with 0700 permissions, and having the client prove that it can
      read the cookie. This never actually worked for non-malicious clients in
      the case where server uid != client uid (unless the server and client
      both have privileges, such as Linux CAP_DAC_OVERRIDE or traditional
      Unix uid 0) because an unprivileged server would fail to write out the
      cookie, and an unprivileged client would be unable to read the resulting
      file owned by the server.
      
      Additionally, since dbus 1.7.10 we have checked that ~/.dbus-keyrings
      is owned by the uid of the server (a side-effect of a check added to
      harden our use of XDG_RUNTIME_DIR), further ruling out successful use
      by a non-malicious client with a uid differing from the server's.
      
      Joe Vennix of...
      47b1a4c4
  10. 17 May, 2019 2 commits
  11. 13 May, 2019 3 commits
    • Simon McVittie's avatar
      Update NEWS · 74e1cfab
      Simon McVittie authored
      
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      74e1cfab
    • Simon McVittie's avatar
      bus: Try to raise soft fd limit to match hard limit · 94bacc69
      Simon McVittie authored
      Linux systems have traditionally set the soft limit to 1024 and the hard
      limit to 4096. Recent versions of systemd keep the soft fd limit at
      1024 to avoid breaking programs that still use select(), but raise the
      hard limit to 512*1024, while in recent Debian versions a complicated
      interaction between components gives a soft limit of 1024 and a hard
      limit of 1024*1024. If we can, we might as well elevate our soft limit
      to match the hard limit, minimizing the chance that we will run out of
      file descriptor slots.
      
      Unlike the previous code to raise the hard and soft limits to at least
      65536, we do this even if we don't have privileges: privileges are
      unnecessary to raise the soft limit up to the hard limit.
      
      If we *do* have privileges, we also continue to raise the hard and soft
      limits to at least 65536 if they weren't already that high, making
      it harder to carry out a denial of service attack on the system bus on
      systems that use the traditional limit (CVE-...
      94bacc69
    • Clemens Lang's avatar
      cmake: Avoid overwriting PKG_CONFIG_PATH env var · 6e432ed5
      Clemens Lang authored
      
      
      The CMake config file installed by DBus will run in the context of other
      projects. Consequently, changing the value of the PKG_CONFIG_DIR,
      PKG_CONFIG_PATH or PKG_CONFIG_LIBDIR environment variables will affect
      any further calls to pkg-config made by such projects, which can cause
      problems.
      
      A common case of this happening are pkg-config files installed in
      usr/share/pkgconfig for .pc files that are architecture-independent, as
      for example systemd does.
      
      Avoid clobbering the environment variables by saving and restoring their
      values. Note that for some of the variables, setting them to an empty
      string is different from not setting them at all.
      Signed-off-by: default avatarClemens Lang <clemens.lang@bmw-carit.de>
      (cherry picked from commit 3525cc04)
      Closes: #267
      6e432ed5
  12. 18 Apr, 2019 2 commits
  13. 17 Apr, 2019 6 commits