Re: D-Bus policies

[Diederik de Haas <didi.debian at cknow.org>]

[-- Attachment #1: Type: text/plain, Size: 3615 bytes --]

Hi Denis,

On Saturday, 22 January 2022 00:13:14 CET Denis Kenzior wrote:
> Care to send a patch?

I technically can, but before doing that I'd like some clarification on the 
impact of such a patch as I have no-where near enough understanding of both 
D-Bus and iwd of the impact of such a patch. I 'prefer' not to have my name 
attached to a (potential) security breach ;-)

> > Looking into possible solutions, I found 2 very similar commits ...
> > 
> > They both link to
> > https://www.spinics.net/lists/linux-bluetooth/msg75267.html While I lack
> > the knowledge to fully understand what it says I did notice this: "The
> > intent is clear: As long as you are logged in to a local machine, and you
> > are the foreground/active console, you are allowed to control bluetooth.
> > However, the behavior of 'at_console' does *not* match this intent."
> > 
> > In other places I saw the 'at_console' stanza just plainly removed without
> > any replacement, but it could have undesirable consequences for iwd.
> 
> I think the solution chosen in BlueZ which gives blanket permission to
> access iwd D-Bus APIs to any local user is probably just fine. 
> Particularly given that at_console effectively allowed any user to use iwd
> in the past.
> This effectively negates the need to provide a separate policy for
> wheel/netdev and so these can be removed.

Does this mean that any restrictions would be removed?

It is just an example, but the 'deluged' program runs under the 'debian-
deluged' user. If that program has a (security) bug, would that allow a RCE 
wrt to iwd? Could it wreak havoc then?

Looking a bit further to see what others do and found some interesting things.

https://salsa.debian.org/bluetooth-team/bluez/-/blob/debian/sid/debian/
patches/bluetooth.conf.patch is a modification of what upstream bluetooth does 
and adds an allow for the 'bluetooth' group. That patch was explicitly added, 
but without an explanation as to why, but as I understand it now, it means 
that 'bluetooth' group members get access, next to everyone else.
IOW, it _seems_ (to me) like a pointless patch?

In /etc/dbus-1/system.d/wpa_supplicant.conf I see 'allow' for 'root' and 
'netdev' and (explicit) deny for 'context="default"'

In /usr/share/dbus-1/system.d/org.freedesktop.NetworkManager.conf there is a 
FAR more extensive policy, where 'root' can (ofc) do a LOT, but in the default 
context it starts with a 'deny' and then makes exceptions to grant mostly 
ReadOnly access to certain explicitly defined properties. In the comments I see 
things like "read-only properties, no methods" and "read-only, no security 
required".
There seem to be some properties/methods ReadWrite, but additionally secured 
via PolicyKit ("read/write, secured with PolicyKit" in comments).

> Alternatively we can limit the policy only to wheel/netdev groups.

Given the above, I am more inclined to this solution, but it appears to me 
like pretty much the opposite of the other solution?
But it could disallow use cases which iwd was meant to serve, which may be 
undesirable. For example, if I granted access to a friend (over SSH) to my 
machine, he was allowed access to iwd over D-Bus before, but because he's not 
in the netdev group, he would then be denied access.

It could be that iwd only makes a (very) limited(/harmless?) set of 
functionality available over D-Bus, in which case my concerns are unfounded. 
But I lack the knowledge to determine that.

Hope you can alleviate my concerns (before I send in a patch).

Cheers,
  Diederik

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]