My user is in the wheel group: $ id uid=1000(mathieu) gid=1000(mathieu) groups=1000(mathieu),10(wheel),990(mock) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 It's not a super user: $ systemctl status crond.service crond.service - Command Scheduler Loaded: loaded (/lib/systemd/system/crond.service; enabled) Active: active (running) since Mon, 02 Apr 2012 09:48:36 +0800; 1 day and 9h ago Main PID: 888 (crond) $ systemctl restart crond.service Failed to issue method call: Access denied But it's an "administrator" for PolicyKit and sudo: $ sudo systemctl restart crond.service [sudo] password for mathieu: $ systemctl status crond.service crond.service - Command Scheduler Loaded: loaded (/lib/systemd/system/crond.service; enabled) Active: active (running) since Tue, 03 Apr 2012 19:22:27 +0800; 4s ago Main PID: 9932 (crond) [... snip ...] Now, after I install sectool, things change: $ systemctl restart crond.service $ systemctl status crond.service crond.service - Command Scheduler Loaded: loaded (/lib/systemd/system/crond.service; enabled) Active: active (running) since Tue, 03 Apr 2012 19:23:02 +0800; 1s ago Main PID: 9954 (crond) [... snip ...] It doesn't seem right that installing a package suddenly grants my user new permissions. This was first observed by Colin (CC-ed) on Mageia, but I can confirm it also happens on Fedora 16 with sectool-0.9.5-4.fc15.x86_64.rpm
Colin also identified the specific file that causes it: org.fedoraproject.sectool.mechanism.conf When the file is moved away from /etc/dbus-1/system.d/, the bug goes away. I suspect this piece: <policy context="default"> <allow ...something... /> <allow send_type="method_call"/> </policy> I don't know the DBus language, but I assume the two <allow> directives are treated independently. So any method calls to anything get allowed :-)
Yup, that sounds likely Michal (I'm also don't speak DBus policy, so can't offer any more than that!). Just for clarity, it doesn't matter what groups your user is in. My test user not in the wheel group could quite happily fiddle about with stuff. This would appear to tie in with Michal's observations too.
I expect the two allow directives has the desired meaning only while combined in one <allow send_destination="org.fedoraproject.sectool.mechanism" send_type="method_call"/>. This would mean - allow method_call for destination .sectool (but see later). Because according to dbus-daemon manual page, method_call is denied by default. But "The <deny> element's attributes determine whether the deny "matches" a particular action. If it matches, the action is denied *(unless later rules in the config file allow it)*.". So the allow send_type without a specific destination overrides it. I checked .conf files for other PK based mechanisms and it's not needed to allow method_call, it's allowed just by allow send_destination. Then the easiest fix is to remove the offending line, sectool works and there's no privileges escalations. I just wonder in how many other dbus services we can find this... Man page: http://dbus.freedesktop.org/doc/dbus-daemon.1.html Btw. it's just my observation and it's not clear from man page and I don't speak DBus policy language neither :)
sectool-0.9.5-7.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/sectool-0.9.5-7.fc17
sectool-0.9.5-7.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/sectool-0.9.5-7.fc16
Looks like the patch to fix this is here: http://pkgs.fedoraproject.org/gitweb/?p=sectool.git;a=blob;f=sectool-0.9.5-dbus.patch;h=aedb3ef7f7e5ab22d5438bfb7eee63489ccf3244;hb=4859832281f0e08c6fbe48fc252c4199a0e9e322 But is not yet upstream. We'll need to request a CVE for this.
CVE request and notification on oss-security: http://openwall.com/lists/oss-security/2012/04/03/8
Assigned CVE as per http://www.openwall.com/lists/oss-security/2012/04/04/2
sectool-0.9.5-7.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
sectool-0.9.5-7.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.