[Bug 871943] Re: pam_motd sometimes inherits umask of user (via pam_umask)

Sun Oct 30 16:00:25 UTC 2011

This bug was fixed in the package pam - 1.1.3-5ubuntu1

---------------
pam (1.1.3-5ubuntu1) precise; urgency=low

  * Merge from Debian unstable.  Remaining changes:
    - debian/libpam-modules.postinst: Add PATH to /etc/environment if it's
      not present there or in /etc/security/pam_env.conf. (should send to
      Debian).
    - debian/libpam0g.postinst: only ask questions during update-manager when
      there are non-default services running.
    - Change Vcs-Bzr to point at the Ubuntu branch.
    - debian/patches-applied/series: Ubuntu patches are as below ...
    - debian/patches-applied/ubuntu-rlimit_nice_correction: Explicitly
      initialise RLIMIT_NICE rather than relying on the kernel limits.
    - debian/patches-applied/pam_motd-legal-notice: display the contents of
      /etc/legal once, then set a flag in the user's homedir to prevent
      showing it again.
    - debian/update-motd.5, debian/libpam-modules.manpages: add a manpage
      for update-motd, with some best practices and notes of explanation.
    - debian/patches/update-motd-manpage-ref: add a reference in pam_motd(8)
      to update-motd(5)
    - debian/libpam0g.postinst: drop kdm from the list of services to
      restart.
    - debian/libpam0g.postinst: check if gdm is actually running before
      trying to reload it.
    - debian/local/common-session{,-noninteractive}: Enable pam_umask by
      default, now that the umask setting is gone from /etc/profile.
    - debian/local/pam-auth-update: Add the new md5sums for pam_umask addition.
    - add debian/patches-applied/pam_umask_usergroups_from_login.defs.patch:
      Deprecate pam_unix' explicit "usergroups" option and instead read it
      from /etc/login.def's "USERGROUP_ENAB" option if umask is only defined
      there. This restores compatibility with the pre-PAM behaviour of login.
      (Closes: #583958)
  * Dropped changes, included in Debian:
    - debian/patches-applied/CVE-2011-3148.patch
    - debian/patches-applied/CVE-2011-3149.patch
    - debian/patches-applied/update-motd: updated to use clean environment
      and absolute paths in modules/pam_motd/pam_motd.c.
  * debian/libpam0g.postinst: the init script for 'samba' is now named 'smbd'
    in Ubuntu, so fix the restart handling.
  * debian/patches-applied/update-motd: set a sane umask before calling
    run-parts, and restore the old mask afterwards, so /run/motd gets
    consistent permissions.  LP: #871943.
  * debian/patches-applied/update-motd: new module option for pam_motd,
    'noupdate', which suppresses the call to run-parts /etc/update-motd.d.
    LP: #805423.

pam (1.1.3-5) unstable; urgency=low

  [ Kees Cook ]
  * debian/patches-applied/pam_unix_dont_trust_chkpwd_caller.patch: use
    setresgid() to wipe out saved-gid just in case.
  * debian/patches-applied/008_modules_pam_limits_chroot:
    - fix off-by-one when parsing configuration file.
    - when using chroot, chdir() to root to lose links to old tree.
  * debian/patches-applied/022_pam_unix_group_time_miscfixes,
    debian/patches-applied/026_pam_unix_passwd_unknown_user,
    debian/patches-applied/054_pam_security_abstract_securetty_handling:
    improve descriptions.
  * debian/patches-applied/{007_modules_pam_unix,055_pam_unix_nullok_secure}:
    drop unneeded no-op change to reduce delta from upstream.
  * debian/patches-applied/hurd_no_setfsuid: check all set*id() calls.
  * debian/patches-applied/update-motd: correctly clear environment when
    building motd.
  * debian/patches-applied/pam_env-fix-overflow.patch: fix stack overflow
    in environment file parsing (CVE-2011-3148).
  * debian/patches-applied/pam_env-fix-dos.patch: fix DoS in environment
    file parsing (CVE-2011-3149).

pam (1.1.3-4) unstable; urgency=low

  * Make sure shared library links are also installed to the multiarch
    directory, not just the .a files; otherwise the static libs get found
    first by the linker.  Thanks to Russ Allbery for catching this.
    Closes: #642952.

pam (1.1.3-3) unstable; urgency=low

  * Look for /etc/init.d/postgresql, not /etc/init.d/postgresql-8.{2,3},
    for service restarts; the latter are obsolete since squeeze.
    Closes: #631511.
  * Move debian/libpam0g-dev.install to debian/libpam0g-dev.install.in
    and substitute the multiarch path at build time, so our .a files go to
    the multiarch dir instead of to /usr/lib.  Thanks to Riku Voipio for
    pointing out the bug.
  * debian/control: adjust the package descriptions, as the current ones
    use some awkward language that's gone unnoticed for a long time.  Thanks
    to Martin Eberhard Schauer <Martin.E.Schauer at gmx.de> for pointing this
    out.  Closes: #633863.
  * Build-depend on debhelper 8.9.4 and bump debian/compat to 9 for
    dpkg-buildflags integration, and drop manual setting of -g -O options in
    CFLAGS now that we can let dh do it for us
  * Don't set --sbindir when calling configure; upstream takes care of this
    for us
 -- Steve Langasek <steve.langasek at ubuntu.com>   Sun, 30 Oct 2011 09:45:00 -0600

** Changed in: pam (Ubuntu)
       Status: Triaged => Fix Released

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2011-3148

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2011-3149

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to pam in Ubuntu.
https://bugs.launchpad.net/bugs/871943

Title:
  pam_motd sometimes inherits umask of user (via pam_umask)

Status in “pam” package in Ubuntu:
  Fix Released

Bug description:
  When performing install audits, I noticed that /run/motd had the following permissions:
  $ ls -l /run/motd
  -rw-rw-r-- 1 root root 198 2011-10-10 13:20 /run/motd

  I found this odd and remembered
  https://blueprints.launchpad.net/ubuntu/+spec/umask-to-0002. While
  /etc/init/mounted-run.conf creates this initially on reboot, it turns
  out that the permissions are changed on login, via pam_motd.

  TEST CASE:
  1. login
  2. sudo chmod 644 /run/motd
  3. Check the permissions of /run/motd. Eg:
  $ ls -l /run/motd
  -rw-r--r-- 1 root root 198 2011-10-10 13:20 /run/motd
  4. login via ssh (eg ssh 127.0.0.1)
  5. Check the permissions of /run/motd. Eg:
  $ ls -l /run/motd
  -rw-rw-r-- 1 root root 198 2011-10-10 13:38 /run/motd

  So, this happens on ssh logins and not console logins because pam_motd
  in console logins is earlier in the stack (before common-session,
  which has pam_umask in it). With ssh logins, pam_motd is after common-
  session.

  This does not seem to be a security issue as the umask has to be
  adjusted via /etc/login.defs; however the side-effect is undesirable.
  While we could adjust the stacking, it seems a reasonable hardening
  measure would be for pam_motd to explicitly set its umask.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pam/+bug/871943/+subscriptions