Score:3

Prevent specific users from turning off network connections

ar flag

There is a customised Ubuntu 22.04 system with 4 users: user_a, user_b, user_c, user_d

I want to prevent 2 users (user_c, user_d) from changing Ubuntu settings. I've already locked down the terminal for these users using rbash.

Using setfacl, the GNOME Control Center has been disabled for user_c, user_d. This was done by running this code (in a systemd service with sudo privileges):

sudo setfacl -m g:user_c:- -R /usr/bin/gnome-control-center
sudo setfacl -m g:user_d:- -R /usr/bin/gnome-control-center

This effectively restricts access for user_c, user_d so that they can't even view the system settings. user_c,user_d cannot change the Network connection settings. For example, in user_c/user_d, clicking 'Wired Settings' for any of the connections does nothing. This is fine. See image Ubuntu Network connection list

Now the question is: How can we prevent these users (user_c, user_d) from turning the network connections ON/OFF? (i.e. How do we hide that the 'Turn Off' button in the connections drop-down menu).

Other users (user_a, user_b) should still be able to turn the network connections on/off and change the settings.

Score:2
us flag

gnome-control-center talks to NetworkManager (via D-Bus) for configuring the network.

Even if the user cannot run the gnome-control-center application, they still can directly talk to NetworkManager via D-Bus. For example, via nmcli or nm-connection-editor or just plain dbus-send. Restricting which programs a user can run, won't work -- unless you care about only blocking users who would not know any better.

The way to restrict access to NetworkManager is via PolicyKit. See nmcli general permissions for the actions, and which permissions the user has. Configure PolicyKit to restrict that to certain users. How to do that exactly, is a longer story.

Most read-only operations in NetworkManager however don't get checked by PolicyKit. Every user who can talk to D-Bus, can see them. To prevent a user to even see that, configure dbus-daemon (it also has policies that can prevent users from seeing the NetworkManager API). that again would be a longer story.

Finally, D-Bus works by using a unix socket (e.g. /var/run/dbus/system_bus_socket). You can also take the unix permissions away from that user to even access D-Bus at all. However, that might break a lot of things, because D-Bus is just an IPC mechanism, and you basically disable this kind of inter process communication for the user, which may be too limiting (depending on what they should do).

How can we prevent these users (user_c, user_d) from turning the network connections ON/OFF?

nmcli general permissions lists org.freedesktop.NetworkManager.enable-disable-network PolicyKit permission. Disallow the user that.

EDIT: The permissions in the org.freedesktop.NetworkManager.policy PolicyKit file can be edited using the PolicyKit file found at:

/usr/share/polkit-1/actions/org.freedesktop.NetworkManager.policy

For the following actions, the permissions that are set to 'yes' by default, should be changed to 'auth_admin' :

org.freedesktop.NetworkManager.settings.modify.own
org.freedesktop.NetworkManager.network-control
org.freedesktop.NetworkManager.enable-disable-network 

('yes' means that the action is allowed for any users. 'auth_admin' means that the action needs to authenticated by administrative users)

Initially, I had tried only modifying the permissions for org.freedesktop.NetworkManager.enable-disable-network action. However, I noticed that the non-admins could still turn the network connections on/off. So I included these other actions (listed above) as well. This may be a bit overkill. But it works well.

Now it works as expected: For non-admin users, the option to configure the Network connection is disabled. An admin user can turn on/off the network connection after entering the password.

The different actions & permissions are documented at freedesktop.org/software/polkit/docs/latest/polkit.8.html

I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.