Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 631546

Summary: sys-auth/polkit: root privilege escalation via "chown -R" in pkg_postinst
Product: Gentoo Security Reporter: Michael Orlitzky <mjo>
Component: AuditingAssignee: Gentoo Security <security>
Status: CONFIRMED ---    
Severity: normal CC: asturm, eva, kensington, mrueg, pacho, perfinion, security-audit
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---

Description Michael Orlitzky gentoo-dev 2017-09-20 17:07:36 UTC
The ebuilds for polkit call "chown -R" on the live root filesystem in pkg_postinst:

  pkg_postinst() {
      chown -R polkitd:root "${EROOT}"/{etc,usr/share}/polkit-1/rules.d
      chown -R polkitd:polkitd "${EROOT}"/var/lib/polkit-1
  }

That can be exploited by the "polkitd" user (and possibly anyone in the "polkitd" group) to gain root. If a hard link is placed in /var/lib/polkit-1 pointing to a root-owned file, then the next time polkit is reinstalled or upgraded, the "chown -R" will affect the *target* of the link. For example,

  1. emerge polkit
  2. su -s /bin/sh -c 'ln /etc/passwd /var/lib/polkit-1/x' polkitd
  3. emerge polkit
  4. /etc/passwd is owned by polkitd:polkitd

If any of the files on which "chown" are called happen to be group-writable, then the same problem exists for the group. At the least, the same trick can generally make root's files readable by the polkitd group.
Comment 1 Gilles Dartiguelongue gentoo-dev 2017-09-30 09:24:14 UTC
Would changing to fowners solve the issue or should we resort to some find command excluding hardlinks ?
Comment 2 Michael Orlitzky gentoo-dev 2017-09-30 11:22:50 UTC
src_install already calls fowners on one set of paths,

  fowners -R polkitd:root /{etc,usr/share}/polkit-1/rules.d

and the "diropts" ensures that /var/lib/polkit-1 has the correct owner:

  diropts -m0700 -o polkitd -g polkitd
  keepdir /var/lib/polkit-1

(I think diropts affects keepdir? If not, a "dodir" may need to be added.)

So the question is, why did someone think it was necessary to repeat those calls in pkg_postinst? If there's no real reason for it, then the best way to deal with it is to simply delete pkg_postinst(). However, if there is a real issue that the "chown -R" calls are intended to fix, then we'll need to know what that issue is before trying to fix the vulnerability.

My guess is that pkg_postisnt was added "just to be safe" without realizing the risk it posed. It's up to you if you're willing to delete it as part of a grand experiment, though.
Comment 3 Pacho Ramos gentoo-dev 2017-09-30 11:33:32 UTC
I think that, either in this case or the gdm one, they were added to cover updates from older versions not setting proper permissions... but I don't remember
Comment 4 Michael Orlitzky gentoo-dev 2017-09-30 14:47:58 UTC
(In reply to Pacho Ramos from comment #3)
> I think that, either in this case or the gdm one, they were added to cover
> updates from older versions not setting proper permissions... but I don't
> remember

I've been collecting advice for how to fix these, and "fixing permissions from an old version" is the one truly difficult case. If that's what we have here, then these are the recommendations that I've collected so far:

  1. If possible, only operate on a specific list of paths. In other words,
     don't use "--recursive" just to save yourself some typing.

  2. If you don't have an explicit list of paths, then use "find" to collect
     the list of targets. The -user, -group, and -perm flags can ensure that
     you only find those paths that actually need fixing.

  3. Always use the "--no-dereference" flag with chown and chmod to avoid 
     following symlinks created by an unprivileged user.

  4. If you're fixing incorrect ownership from an old version of your package, 
     then you should know who the previous (wrong) owner is. Use the "--from"
     flag to chown to ensure that the old owner can't swap out one of his
     files with a hard link to a root-owned file.

  5. Tighten permissions in a top-down fashion. If you need to tighten the 
     permissions on /etc/foo and all of its contents, then tighten the 
     permissions on /etc/foo first. That way, the operations that you perform
     on its contents are safer. If you're loosening permissions, do it the
     other way around.
Comment 5 Michael Orlitzky gentoo-dev 2017-09-30 14:52:14 UTC
And actually, I'll go add a sixth right now:

  6. Check REPLACING_VERSIONS[0][1] and only fix permissions when upgrading
     from a version that set them incorrectly.


[0] https://devmanual.gentoo.org/ebuild-writing/eapi/index.html
[1] https://projects.gentoo.org/pms/6/pms.html#x1-12200011.1.2
Comment 6 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2020-04-03 23:16:30 UTC
Unrestricting and reassigning to security@ per bug #705894
Comment 7 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2020-04-03 23:18:19 UTC
unrestricting per bug 705894