Re: D-Bus policies

[Denis Kenzior <denkenz at gmail.com>]

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

Hi Diederik,

On 1/25/22 08:49, Diederik de Haas wrote:
> 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 ;-)
> 

No worries.

>>> 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?
>

Yes, basically any logged in user could use iwctl or dbus-send to control iwd 
via the D-Bus API.  So any user could switch networks, power device up and down, 
etc.

This would be similar to BlueZ, where any user could control the bluetooth device.


> 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?
> 

In theory, not really, since it would still have to go through the D-Bus API and 
the associated checks.  So it couldn't execute arbitrary code, but it could do 
anything that a normal user can do as described above.

> 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?

Seems pointless to me as well.  The intent seems to be to allow Bluetooth 
control only by the users of the 'bluetooth' group.  But I don't think that's 
what is actually happening due to the context="default" hole being punched.

> 
> 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).
> 

Right, I don't think we really want to go that far and our APIs are quite simple 
compared to NM.  Our goal is to ship a minimal policy that works for most users 
out of the box.  If the distros need something else, they're free to modify the 
policy as they see fit.

>> 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?

Sort of.  I think in reality the vast majority of users are on single-user 
systems with the main user already part of the 'wheel' group.  So even if we 
drop the at_console usage, and allowed iwd use only for root/netdev/wheel, the 
impact should be minimal.

> 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.

Correct.  But how likely is this scenario? :)

> 
> 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
> 


Regards,
-Denis