Bug 18985

Summary:	explicitly allow Introspection and other disallowed interfaces
Product:	hal	Reporter:	Colin Walters <walters>
Component:	hald	Assignee:	David Zeuthen (not reading bugmail) <zeuthen>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	medium	CC:	bugzilla, danny.kukawka, kai.kasurinen, richard, walters
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:
Attachments:	allow introspection proposed hal.conf.in allow introspection and Device.KillSwitch access

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.