Summary: | sys-auth/polkit-0.107-r1 should use root:polkitd instead of polkitd:root for /etc/polkit-1/rules.d and /usr/share/polkit-1/rules.d | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Maxim Kammerer <mk> |
Component: | [OLD] Core system | Assignee: | Nirbheek Chauhan (RETIRED) <nirbheek> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | derk.tebokkel, freedesktop-bugs |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=420269 https://bugs.freedesktop.org/show_bug.cgi?id=58787 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Maxim Kammerer
2012-11-25 20:36:02 UTC
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. |