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