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.
Would changing to fowners solve the issue or should we resort to some find command excluding hardlinks ?
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.
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
(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.
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
Unrestricting and reassigning to security@ per bug #705894
unrestricting per bug 705894
(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 After 5 years, do we still need to worry about these broken older versions?
