Bug#839124: lintian: please add some helpful advice how to fix tags/dbus-policy-at-console
Hi, On Sat, Dec 16, 2017 at 04:50:37PM +, Simon McVittie wrote: > Sending this specifically to you in case you missed it, since you weren't > in Cc at the time: thanks, I did indeed miss it, though Chris now made me aware, but then I postponed looking into this… so you made me revisit this earlier, thanks for that! > for debian-edu-config, you don't need documentation > for how to replace /etc/dbus-1/system.d/hal-debian-edu.conf because I'm > fairly sure it already has no practical effect: > > 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. > > hal was most recently in Debian as part of wheezy (oldoldstable), so > the file triggering the lintian warning in debian-edu-config is useless > and can safely be removed, unless debian-edu has some lookaside package > repository with packages that are no longer in Debian (in which case I > would still recommend dropping hal as soon as possible, because it > hasn't been maintained for years). thanks for all that information. and no, Debian Edu Wheezy was the last Debian Edu release where we had some packages different than Debian stable. Which were 5 packages where we had a bit different versions… see http://ftp.skolelinux.org/skolelinux/wheezy_needs_love.html (and change wheezy with squeeze, etch or lenny if you want to dig further ;) I've now did this change in debian-edu-config.git: + * Drop dbus-1/system.d/hal-debian-edu.conf, as Wheezy was the last Debian +version including hal, so since Jessie this file was without any effect. +(See #839124 for more information.) > If you want to configure access control for the services that replaced > hal, you'll need to write polkit policies (but if nobody has noticed a > problem with them, their defaults might well be fine for your use case). /me nods. Thanks for everyone explaining this situation! -- cheers, Holger signature.asc Description: PGP signature
Bug#839124: lintian: please add some helpful advice how to fix tags/dbus-policy-at-console
On Sat, 16 Dec 2017 at 10:53:22 +, Holger Levsen wrote: > On Sat, Dec 16, 2017 at 10:21:40AM +, Chris Lamb wrote: > > [Adding Holger, the original submitter, to the CC - please see the last two > > messages for some more context] > > Wow, thank you so much for the detailed explanation! > > indeed & thank you too for keeping me in the loop. > > This is great news as I'd like to get rid of these issues in > src:debian-edu-config for buster and it seems there's now enough > documentation that we'll be able to do so. Sending this specifically to you in case you missed it, since you weren't in Cc at the time: for debian-edu-config, you don't need documentation for how to replace /etc/dbus-1/system.d/hal-debian-edu.conf because I'm fairly sure it already has no practical effect: 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. hal was most recently in Debian as part of wheezy (oldoldstable), so the file triggering the lintian warning in debian-edu-config is useless and can safely be removed, unless debian-edu has some lookaside package repository with packages that are no longer in Debian (in which case I would still recommend dropping hal as soon as possible, because it hasn't been maintained for years). If you want to configure access control for the services that replaced hal, you'll need to write polkit policies (but if nobody has noticed a problem with them, their defaults might well be fine for your use case). smcv
Bug#839124: lintian: please add some helpful advice how to fix tags/dbus-policy-at-console
On Sat, Dec 16, 2017 at 12:01:56PM +, Simon McVittie wrote: > Yes - if I knew how to summarize it in a form short enough for a Lintian > tag description, I would already have done so. a link to a longer description would also do :) -- cheers, Holger signature.asc Description: PGP signature
Bug#839124: lintian: please add some helpful advice how to fix tags/dbus-policy-at-console
On Sat, 16 Dec 2017 at 10:21:40 +, Chris Lamb wrote: > Alas, however, I'm finding it difficult summarising it in the Lintian > description for this tag to solve Holger's original question/query. Yes - if I knew how to summarize it in a form short enough for a Lintian tag description, I would already have done so. > … or perhaps we should wait until the aforementioned docs are written such > that we can link to them? I think that's probably the only approach that's going to work. smcv
Bug#839124: lintian: please add some helpful advice how to fix tags/dbus-policy-at-console
Hi, On Sat, Dec 16, 2017 at 10:21:40AM +, Chris Lamb wrote: > [Adding Holger, the original submitter, to the CC - please see the last two > messages for some more context] > Wow, thank you so much for the detailed explanation! indeed & thank you too for keeping me in the loop. This is great news as I'd like to get rid of these issues in src:debian-edu-config for buster and it seems there's now enough documentation that we'll be able to do so. That said, doing so is probably something for 2018 ;) -- cheers, Holger signature.asc Description: PGP signature
Bug#839124: lintian: please add some helpful advice how to fix tags/dbus-policy-at-console
[Adding Holger, the original submitter, to the CC - please see the last two messages for some more context] Hi Simon, Wow, thank you so much for the detailed explanation! > In general: writing some document on how to replace use of at_console > policies (and in general all 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. That's absolutely fine and thank you so much for your detailed explanation you provided in your previous mail! Alas, however, I'm finding it difficult summarising it in the Lintian description for this tag to solve Holger's original question/query. Can you help? The description for the tag is: Tag: dbus-policy-at-console Severity: normal Certainty: certain Info: The package contains D-Bus policy configuration that uses the deprecated at_console condition to impose a different policy for users who are "logged in at the console" according to systemd-logind, ConsoleKit or similar APIs, such as: . policy context="default" deny send_destination="com.example.PowerManagementDaemon"/ /policy policy at_console="true" allow send_destination="com.example.PowerManagementDaemon"/ /policy . The maintainers of D-Bus recommend that services should allow or deny method calls according to broad categories that are not typically altered by the system administrator (usually either "all users", or only root and/or a specified system user). If finer-grained authorization is required, the service should accept the method call message, then call out to PolicyKit to decide whether to honor the request. PolicyKit can use system-administrator-configurable policies to make that decision, including distinguishing between users who are "at the console" and those who are not. Ref: https://bugs.freedesktop.org/show_bug.cgi?id=39611 … or perhaps we should wait until the aforementioned docs are written such that we can link to them? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#839124: lintian: please add some helpful advice how to fix tags/dbus-policy-at-console
On Fri, 15 Dec 2017 at 22:41:10 +, 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 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 and
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 to control : 99% of the time the
correct answer is
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
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
rules for your service, and replace them with allowing everyone to
send method calls to your service:
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
Bug#839124: lintian: please add some helpful advice how to fix tags/dbus-policy-at-console
[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? Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#839124: lintian: please add some helpful advice how to fix tags/dbus-policy-at-console
Package: lintian Severity: wishlist Hi, 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. Please improve the tag description so it becomes more clear what should be done. Thanks for maintaining lintian! -- cheers, Holger signature.asc Description: Digital signature
