Bug 18985 - explicitly allow Introspection and other disallowed interfaces
Summary: explicitly allow Introspection and other disallowed interfaces
Status: RESOLVED FIXED
Alias: None
Product: hal
Classification: Unclassified
Component: hald (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: David Zeuthen (not reading bugmail)
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-12-09 12:12 UTC by Colin Walters
Modified: 2009-01-29 06:37 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Attachments
allow introspection (562 bytes, patch)
2008-12-09 12:12 UTC, Colin Walters
Details | Splinter Review
proposed hal.conf.in (707 bytes, patch)
2008-12-10 12:35 UTC, Colin Walters
Details | Splinter Review
allow introspection and Device.KillSwitch access (1.03 KB, patch)
2008-12-19 11:27 UTC, Colin Walters
Details | Splinter Review

Description Colin Walters 2008-12-09 12:12:30 UTC
Created attachment 20960 [details] [review]
allow introspection

Right now HAL has a lot of manual interface rules in the allow; if we're really using PolicyKit now it seems to me we could replace all of them with the simple:

<allow send_destination="org.freedesktop.Hal"/>

But I've chosen to attach a patch which is conservate and just explicitly enables introspection.
Comment 1 Colin Walters 2008-12-10 12:35:52 UTC
Created attachment 21023 [details] [review]
proposed hal.conf.in

Propose replacing the existing .conf.in with this upstream, moving the other one to hal-nopolicykit.conf.in.  (Possibly add a configure option?)
Comment 2 Colin Walters 2008-12-18 13:51:00 UTC
Ping on this bug - I want to do a new dbus release with logging, and NetworkManager talking to HAL constantly warns about the KillSwitch method.
Comment 3 Richard Hughes 2008-12-19 02:04:50 UTC
I think we need to discuss this upstream. I would prefer a much less invasive patch as HAL is in effective feature freeze.
Comment 4 Colin Walters 2008-12-19 08:53:02 UTC
(Aren't we discussing this upstream now?)  Ok, I'll see about putting together a targeted patch.
Comment 5 Colin Walters 2008-12-19 11:27:29 UTC
Created attachment 21326 [details] [review]
allow introspection and Device.KillSwitch access

This one just allows introspection and Device.KillSwitch access.  There may be others.
Comment 6 Simon McVittie 2009-01-05 07:39:06 UTC
For reference, this is Debian bug <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510639>; I put some notes and proposed patches there while trying to fix it in the (older?) version used in Debian 5.0.

A perhaps-simpler way to fix NetworkManager's use of hal would be to allow root to access all of hal's functionality, which I've proposed as a patch to the Debian package. Since root is allowed to replace or impersonate hal, being able to access hal seems fairly uncontroversial.

hal also has the bug tracked by <http://bugs.freedesktop.org/show_bug.cgi?id=18961> (send_interface without send_destination) which I've proposed as a patch; it won't apply upstream without minor modification since I applied it after the Debian-specific group-based access control patch, but the changes are hopefully obvious.

According to some quick testing, gnome-power-manager (at least at the version in Debian 5.0) also wants to access the CPUFreq interface, so that should probably be allowed for users who are at_console (or some other suitable access control - in Debian it's the powerdev group, but that's Debian-specific anyway). I also suggested allowing DockStation and WakeOnLan, which seemed in-scope for the Debian powerdev group.

Which other interfaces have I missed, that are "fairly safe" for users with physical access?
Comment 7 Simon McVittie 2009-01-05 07:50:37 UTC
This also seems to be https://bugzilla.redhat.com/show_bug.cgi?id=476043
Comment 8 Danny Kukawka 2009-01-29 06:37:18 UTC
It should be fixed now in git master. 

Check: http://cgit.freedesktop.org/hal/tree/hal.conf.in


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.