On Fri, 15 Dec 2017 at 22:41:10 +0000, Chris Lamb wrote: > [Adding Simon to CC] > > Holger wrote: > > > I reported on IRC and Niels asked me to file this bug and CC: Simon: > > > > https://lintian.debian.org/tags/dbus-policy-at-console.html is not very > > helpful in fixing the issue at hand, the referenced bug doesnt really > > tell anything about how we should modify > > https://anonscm.debian.org/git/debian-edu/debian-edu-config.git/tree/etc/dbus-1/system.d/hal-debian-edu.conf > > to get rid of this lintian warning. > > Simon, I think you were omitted from the CC :) Can you help here?
In this specific case: you should probably drop the file (preferably into a bonfire), since HAL is very, very obsolete, and I very much hope debian-edu no longer uses or ships it. The parts of HAL where high-level APIs made sense were replaced by the DeviceKit services, which were later renamed to or replaced by udisks, upower and possibly others; lower-level device enumeration and change-notification were superseded by using udev directly. In general: writing some document on how to replace use of at_console policies (and in general all <allow send_*> rules) with polkit has been on my to-do list for a while, but it deserves a better writeup than I am able to do right now. The tl;dr version is that it's something for the upstream developers of D-Bus services to solve in their API designs, and udisks2 is a particularly good example to look at. It goes something like this: 1. Make sure your service doesn't emit broadcast signals that are considered to be confidential, because that makes little sense - 99% of the time this is already the case - otherwise this is an incompatible D-Bus API change which will need to be coordinated like any other API break 2. Remove your service's <policy><allow receive_*></policy> and <policy><deny receive_*> rules, and rely on the default policy, which is that unicast messages like method calls can be received by their intended destination, and broadcast signals can be received by everyone 3. Continue to use <policy> to control <allow own>: 99% of the time the correct answer is <policy user="the system user you always run as"> <allow own="your bus name"/> </policy> 4. Classify the D-Bus method calls available on your service into: - OK for any user to call at any time (org.freedesktop.Properties.Get is usually like this) - Only OK to call by actively-logged-in users, or by privileged users, or with some other access control restrictions (for instance a method like MountDiskDevice() would be restricted like this; these are the methods that probably had non-trivial <policy> applied to them) 5. Group together the D-Bus method calls that need restriction into *actions*, which is polkit's term for something that it restricts: in simple cases there might be one action for the whole service or one per method, but more commonly they won't correspond 1:1. udisks2 is a good example: mounting a disk is one method call, but it maps to one of several actions, depending whether the disk is removable, whether a removable disk is on the same "seat" as the user and so on. The finest-grained control that sysadmins can have is on a per-action basis, so more specific actions are usually better, within reason. 6. Write polkit policy files for the actions. These give a human-readable description for the action (used when prompting about it), and set the default policy if the sysadmin has not overridden it. See polkit(8). 7. In the service's source code, when you receive a request that needs access control, don't obey the request immediately. Instead, remember all the necessary information to resume the request, ask polkitd whether you should obey the request or not (usually by using a PolkitAuthority object), and wait for a response. When you get a response from polkitd, either obey the request or send back a "permission denied" error, depending what polkitd told you to do. 8. Now that your service is ready to take full responsibility for enforcing its own security boundary (which it does by asking polkitd what the right policy is), remove the <policy><allow send_*></policy> rules for your service, and replace them with allowing everyone to send method calls to your service: <policy context="default"> <allow send_destination="your bus name"/> </policy> 9. Sysadmins (and config packages like debian-edu-config) can configure polkit 0.105 (Debian !experimental, Ubuntu) by dropping .ini-style files into /{etc,var/lib}/polkit-1/localauthority/*.d, or can configure polkit 0.11x (Debian experimental and most other distros) by dropping JavaScript files into /{etc,usr/share}/polkit-1/rules.d. These files selectively change the policies for particular actions to whatever is considered most appropriate for this particular system. polkit 0.105 has a system of prioritized sources of configuration, which with hindsight was more complex than it was worth. polkit 0.11x uses a simpler system, a lot like systemd, where OS-vendor defaults go in /usr/share and sysadmin overrides go in /etc. If using a version that uses JavaScript, this is "JavaScript as embeddable domain-specific language" (the same niche that's often filled by Lua), so it has little to do with web browsers or nodejs except for reusing a syntax. In particular the scripts are totally trusted (only root can edit them, only root runs them), there are no third party libraries (just the core language and some polkit-specific functions), and there is no network access. flatpak and gnome-control-center have some good examples of policies being overridden: both adjust the rules so that members of the sudo group can do a few actions that would normally require root-equivalent authentication (meaning their own password or root's password, because Debian configures polkit to treat the sudo group as root-equivalent) without actually needing a password prompt. This is only needed because the syntax of polkit defaults doesn't allow that behaviour to be used as a default. I hope that brain-dump helps. At some point I'll write this up in a better-edited form as a blog post or some official dbus/polkit documentation. smcv