PolKit daemon has no reason to write to /etc/polkit-1/rules.d or /usr/share/polkit-1/rules.d. The standard method for giving only polkitd read access to rules.d is root:polkitd ownership + 0750 permissions (rules.d only or including directory contents as well). I don't see anything in bug #420269 that required such ownership change. As it stands now, gaining access to local user polkitd automatically results in system compromise due to ability to rewrite rules. Also, the way ebuild is written, ownership of rules added by other packages is also changed when polkit is built. I suggest non-recursive change of ownership to root:polkitd + mode 0750 of the two rules.d directories during build.
I apply the following fix locally: chown root:polkitd /etc/polkit-1/rules.d chmod 750 /etc/polkit-1/rules.d chown root:root {/etc,/usr/share}/polkit-1/rules.d/* /usr/share/polkit-1/rules.d chmod 644 {/etc,/usr/share}/polkit-1/rules.d/* This results in: # ls -ld /etc/polkit-1/rules.d /usr/share/polkit-1/rules.d drwxr-x--- 2 root polkitd 136 Nov 25 00:14 /etc/polkit-1/rules.d drwxr-xr-x 2 root root 184 Nov 24 23:51 /usr/share/polkit-1/rules.d # ls -ld /etc/polkit-1/rules.d/* /usr/share/polkit-1/rules.d/* -rw-r--r-- 1 root root 321 Nov 23 16:46 /etc/polkit-1/rules.d/50-default.rules -rw-r--r-- 1 root root 286 Nov 24 23:49 /usr/share/polkit-1/rules.d/01-org.freedesktop.ModemManager.rules -rw-r--r-- 1 root root 265 Nov 24 23:51 /usr/share/polkit-1/rules.d/01-org.freedesktop.NetworkManager.settings.modify.system.rules Everything appears to work correctly (I checked many actions with pkcheck).
(In reply to comment #0) > As it stands now, gaining > access to local user polkitd automatically results in system compromise That doesn't seem like a real problem. Local user polkitd uses /sbin/nologin as the login shell, so to access it, the attacker would need to either (1) edit /etc/passwd (and if he can do that, he has already compromised the system); or (2) use a uid-switching tool like su or sudo (and if he can do that, he has already compromised the system); or (3) compromise a running polkitd process (and if he can do that, he has already compromised the system); or (4) compromise a vulnerable executable which is suid polkitd (and AFAIK gentoo doesn't install any suid polkitd executables).
(In reply to comment #2) > (3) compromise a running polkitd process (and if he can do that, he has > already compromised the system); or You are assuming some specific type of attacks. What if polkitd process is compromised in a way that only allows creation of arbitrary files? Besides, I don't like being put in a position of defending sane security practices just because someone did something unnecessary. My point was: what is the purpose of non-root ownership of said files? It was done in the commit fixing bug #420269 -- what prompted it? This looks like a mistake. # find / -xdev ! -user root ! -path '/home/*' ! -path '/var/lib/*' ! -path '/var/log/*' ! -path '/tmp/*' ! -path '/run/*' ! -path '/usr/src/*' ! -path '/usr/portage*' ! -path '/var/tmp/*' ! -path '/var/cache/*' /etc/polkit-1/rules.d /etc/polkit-1/rules.d/50-default.rules /etc/tcsd.conf /usr/games /usr/share/polkit-1/rules.d What makes polkit special? And /usr/games should be above as well, but at least nothing runs under this uid: http://article.gmane.org/gmane.linux.gentoo.devel/77118
(In reply to comment #3) > And /usr/games should be above as well, but at least nothing runs under this uid Meant "shouldn't", and it is there because /usr/games is the home directory of user "games" (just like /var/lib/polkit-1 is for "polkitd"), and user "games" can be also disabled by setting GAMES_USER_DED=root.
The ./configure is printing out: NOTE: The directory /etc/polkit-1/rules.d must be owned by user 'polkitd' and have mode 700 NOTE: The directory /usr/share/polkit-1/rules.d must be owned by user 'polkitd' and have mode 700 And that's how we install the directories, as per instructions provided by upstream. If you wish them to change, file a bug to http://bugzilla.freedesktop.org/ Otherwise I'll have to agree with Comment #2, not going to change this from upstream defaults if there isn't a good reason to
Thanks for the info, I will check with upstream.
