Red Hat Bugzilla – Full Text Bug Listing
|Summary:||CVE-2012-1615 Merely installing sectool grants some permissions to users?|
|Product:||[Fedora] Fedora||Reporter:||Mathieu Bridon <bochecha>|
|Component:||sectool||Assignee:||Peter Vrabec <pvrabec>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||16||CC:||colin, dkopecek, jhrozek, jreznik, mschmidt, pvrabec, xbarry|
|Fixed In Version:||sectool-0.9.5-7.fc16||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-04-06 17:33:01 EDT||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Mathieu Bridon 2012-04-03 07:33:48 EDT
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
Comment 1 Michal Schmidt 2012-04-03 07:47:08 EDT
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 :-)
Comment 2 Colin Guthrie 2012-04-03 08:00:48 EDT
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.
Comment 3 Jaroslav Reznik 2012-04-03 10:07:05 EDT
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 :)
Comment 4 Fedora Update System 2012-04-03 10:54:35 EDT
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
Comment 5 Fedora Update System 2012-04-03 11:26:55 EDT
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
Comment 6 Vincent Danen 2012-04-03 18:49:50 EDT
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.
Comment 7 Vincent Danen 2012-04-03 18:55:28 EDT
CVE request and notification on oss-security: http://openwall.com/lists/oss-security/2012/04/03/8
Comment 8 Kurt Seifried 2012-04-03 23:08:36 EDT
Assigned CVE as per http://www.openwall.com/lists/oss-security/2012/04/04/2
Comment 9 Fedora Update System 2012-04-06 17:33:01 EDT
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.
Comment 10 Fedora Update System 2012-05-26 03:47:02 EDT
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.