Re: Connection policies control


On Sat, 2019-06-15 at 14:36 +0200, Daniel Vázquez via networkmanager-
list wrote:
I'll want to setup a connect security policy like whitelist rules or
similar, some like:
- Users can connect only to any AP with security WPA2

As said, you cannot run you own script that hooks into the policy
decision. Yes, you can install your own policy-kit rules, but those
make decisions based on the system user and the predefined PolicyKit
action that is required for the task at hand.

Currently the only mechanism to influence the permissions of a profile
is setting "connection.profile" property. However, while you cannot
make decisions based on whether the profile is WPA2, you can set
"connection.profile" for all WPA2 profiles accordingly.

On Mon, 2019-06-17 at 12:47 +0200, Daniel Vázquez wrote:
I have previously used
org.freedesktop.NetworkManager.settings.modify.system to allow or
deny authorization of wifi connections. This works in scenario where
the policy is focused to allow/deny know connections or fully
allow/deny actions or use NM by some users. As you said this is not
enough flexible to describe more granulated policies. By other way
custom scripting request to the current existing NM PolicyKit
org.freedesktop.NetworkManager.* actions will don't provide any
advantage for this granularity. Moreover, If asking for a new AP
security schema requires launch a connection, at some early point NM
should provide some hook or new request to this custom policykit

It's not clear what you would really gain from this granularity. To
better understand the use-case, it would be interesting why exactly you
want this (not merely what you want).

I think that described policy is very usual and widely required and I
thought there would be something more widely established already. How
is it being solved, what tools are currently used to apply these
policies in corporate environments?

I don't think it's that widely required.

I'd assume most machines are either servers (where you just grant all
permissions to the wheel/admin group) or a notebook/workstation (where
de-facto there is only one desktop user).

If you require a more complex setup, then it would be interesing to
understand how that exactly looks.

You can grant users permissions like

  - org.freedesktop.NetworkManager.enable-disable-network

to enable/disable certain profiles, and you can grant permissions

  - org.freedesktop.NetworkManager.settings.modify.system
  - org.freedesktop.NetworkManager.settings.modify.own

to create and modify profiles.

If you allow a user to create/modify a profile, then this user already
has a lot of power (to connect to any network you wish). Since policy
decisions are not made based on the content of the profile.

If you alllow a user to activate/deactivate existing profiles, you give
the user less power, but possibly he/she can still do something useful.

In term of PolicyKit, what a user can do translates to PolicyKit
actions (like "").
PolicyKit is very flexible about granting/disallowing an action to a
certin system user (e.g. all users in the "wheel" group).

The "connection.permissions" property of the profile determines whether
the user requires one or the other action. E.g. whether the user
requires org.freedesktop.NetworkManager.settings.modify.system or
org.freedesktop.NetworkManager.settings.modify.own to modify the

"connections.permission" currently only supports the "user:$USERNAME"
setting. There is room for some more complex permissions, maybe
something like


but it's not very clear to me how a scheme should look like or how it
would be useful.


Thank you,

El dom., 16 jun. 2019 a las 8:28, Thomas Haller (<thaller redhat com>
) escribió:
On Sat, 2019-06-15 at 14:36 +0200, Daniel Vázquez via
list wrote:
Hi guys!!

I'll want to setup a connect security policy like whitelist rules
similar, some like:
- Users can connect only to any AP with security WPA2
- User can connect only to any AP in this list [{ssid:wnet01,
mac:E8:AD:A6:BC:EF:F2}, {ssid:wnet02, mac:B0:BE:76:73:20:8E},

First, I looking for any configuration option available on nm,
but I
don't found any. Then, I write little script to test it running
/etc/NetworkManager/dispatcher.d/pre-up.d/ that runs when AP
connection is stablished. But, I can see that the script is
after connection is fully stablished and a valid ip obtained.
not desired, I want to test if AP are OK with our policies before
stablish fully connection, at least before a fully stablished
connection with IP obtained and other pre-shared data. We want to
test the policies are ok running script on preparing connection
or pre-authentication state or similar earlier stage.

I monitorized nm connection process, and I can see nm manages

wlo1: connecting (prepare)
wlo1: using connection 'wnet02'
wlo1: NetworkManager: is now in the 'connecting' state
wlo1: connecting (need authentication)
wlo1: connecting (prepare)
wlo1: connecting (configuring)
wlo1: connecting (getting IP configuration)
wlo1: connecting (checking IP connectivity)
wlo1: connecting (starting secondary connections)
wlo1: conected

How can we run script on first four stages?
Exist any other way, aproach or recommendation to apply this

Thank you guys!!a


NetworkManager uses PolicyKit, see the available policy-kit

 $ nmcli general permissions

and their comment at

Also, a profile can be either restricted to a user, by setting

  nmcli connection modify x_dummy connection.permissions

or it is not.

Depending on whether a profile is restricted, the user requires
permissions to be able to perform certain actions. For example, 




Another relevant permission to your question is

Note that the root user (user-id 0) always gets a pass, regardless
of what you configure
in PolicyKit.

In PolicyKit you can write your own scripts to answer requests in
any way you want,
but only the existing permissions (PolicyKit actions) that
NetworkManager knows are
available there.

I am not sure the system is flexible enough to do exactly what you
want. Maybe.


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]