Re: D-Bus policies

* Re: D-Bus policies
@ 2022-01-25 21:48 Diederik de Haas
  0 siblings, 0 replies; 7+ messages in thread
From: Diederik de Haas @ 2022-01-25 21:48 UTC (permalink / raw)
  To: iwd

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

Hi Denis,

Thanks a lot for your response :-)

On Tuesday, 25 January 2022 16:38:09 CET Denis Kenzior wrote:
> On 1/25/22 08:49, Diederik de Haas wrote:
> > On Saturday, 22 January 2022 00:13:14 CET Denis Kenzior wrote:
> >> 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?
> 
> This would be similar to BlueZ, where any user could control the bluetooth
> device.

Ok, so Option 1 is to lift all restrictions.

> > Looking a bit further to see what others do and found some interesting
> > things.
> > 
> > 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
> 
> 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. 

Agreed that NM is far more extensive. I included it as a 2nd example where 
deny is the default policy, with some explicit exceptions.
But wpasupplicant's policy is far simpler (default deny, root/netdev allow) 
and that program seems comparable to iwd.

> If the distros need something else, they're free to modify the policy as
> they see fit.

Of course they have that freedom, but as noted in my OP, most distros just use 
what's provided upstream. 

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

When I setup a new Debian system, I *manually* add myself to "dialout, adm, 
plugdev, netdev, audio, video" groups, so this is not an automatic thing.
I just added a 2nd user on my system and its only group membership was to a 
group named the same as the user. This is the default behavior, but it may be 
(a bit) different for the first user, but likely also depends on how the system 
is setup.
The 'wheel' group is not used/present on Debian (based distros).

So I think the impact is not minimal. OTOH, it should be common knowledge that 
users need netdev group permissions to modify network connections.

> > 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's the default scenario on Debian and possibly its derivatives.
FTR: I don't want my friend(s) granted permission to change the network 
connection by default. If I want to grant a friend that permission, I would 
add him/her to the netdev group.

And Option 2 is restricted access.

For which Option would you like a patch?

Cheers,
  Diederik

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

^ permalink raw reply	[flat|nested] 7+ messages in thread