No default ACL on some dbus methods

[tweksteen]

Some of the methods exposed via dbus are not covered by the current default policy. This includes the getParameter and setParameter methods.

On a default debian install, as unprivileged user:

$ usbguard get-parameter InsertedDevicePolicy
ERROR: IPC connect: service=usbguard: Operation not permitted
$ dbus-send --system --print-reply --dest=org.usbguard /org/usbguard/Policy org.usbguard.getParameter string:"InsertedDevicePolicy"
method return time=1549540531.655300 sender=:1.79383 -> destination=:1.120734 serial=97 reply_serial=2
   string "apply-policy"

This can be fixed by adding these to the current policy configuration. However, having 2 buses and 2 ACLs makes the administration of any deployment tedious. There is always a risk of future methods to be exposed. Ideally, dbus should be the only bus exposed and the libqb bus dropped.

[hartwork]

Hi @tweksteen,

thanks for the report! Since this ticket is public I'll reply in public. I tried to confirm this issue locally with USBGuard 1.0.0 and found that:

• There are two parameter names supported (source):

  • InsertedDevicePolicy
  • ImplicitPolicyTarget

• For those two partameters, supported values are:

  • for InsertedDevicePolicy: "allow", "block", "reject", "keep", "apply-policy" (source)
  • for ImplicitPolicyTarget: "allow", "block", "reject", "match", "device" and "" (empty) (source)

• (Querying get-parameter using usbguard get-parameter works, e.g. sudo ./usbguard get-parameter InsertedDevicePolicy.)

• Querying get-parameter using unprivileged dbus-send works, e.g. dbus-send --system --print-reply --dest=org.usbguard1 /org/usbguard1 org.usbguard1.getParameter string:InsertedDevicePolicy.

• Invoking set-parameter also works, e.g. dbus-send --system --print-reply --dest=org.usbguard1 /org/usbguard1 org.usbguard1.setParameter string:ImplicitPolicyTarget string:allow. The return value is the value prior to the change.

• Method removeRule also works using unprivileged dbus-send; I have not looked at methods appendRule and applyDevicePolicy yet.

• Current policy file src/DBus/org.usbguard1.policy in Git master…

  • contains three non-existing methods rejectDevice, blockDevice, allowDevice,
  • is installed at /usr/share/polkit-1/actions/org.usbguard1.policy on my Gentoo box,
  • should have prevented an un-authenticated call to removeRule the way I read it but didn't, in practice 🤔,
  • is likely missing entries for methods applyDevicePolicy, getParameter and setParameter.

Unless I am missing something, this seems to indeed allow an unpriviliged local user to allow all future connected USB devices in the current boot provided that the usbguard-dbus daemon is running. That would be some form of limited privilege escalation and a security issue, I suppose.

I'd be happy to try a pull request on the polkit policy file, but I'd first need to understand if and why my local file /usr/share/polkit-1/actions/org.usbguard1.policy is indeed ignored.

@radosroka @Cropi I'm rather new to D-Bus and polkit. Does the above make sense to you? How should we proceed?

Best, Sebastian

[hartwork]

I'd be happy to try a pull request on the polkit policy file, but I'd first need to understand if and why my local file /usr/share/polkit-1/actions/org.usbguard1.policy is indeed ignored.

PS: Part of that is #531 now. I have a feeling that USBGuard needs may need additional call-outs to polkit, a bit like the C/C++ version of what article https://vwangsf.medium.com/creating-a-d-bus-service-with-dbus-python-and-polkit-authentication-4acc9bc5ed29 is describing for Python. Could it be that polkit integration into USBGuard was never finished and hence is incomplete as of today? Then (after PR #531) its no longer polkit ignoring files but USBGuard not calling polkit. What do you think?

[hartwork]

Could it be that polkit integration into USBGuard was never finished and hence is incomplete as of today?

Turns out exactly that^^ is the case. I have added the missing calls to Polkit to usbguard-dbus today in PR #531 so that it now provides a complete fix to the issue.

[radosroka]

@hartwork thank you for all the investigation and work you have done. I wasn't involved when dbus part was created so I didn't know.