Hi On Wed, 2020-04-22 at 17:55 +0200, Michael Biebl wrote:
for a bit of backstory: in Debian we traditionally ship a strict PolicyKit configuration for NetworkManager, which doesn't allow non-admin users to edit system wide connections (we build NM with --disable-modify-system, i.e. we use auth_admin_keep instead of yes) The reason for that is, that we want to be able to ship a default policy which is reasonably secure on a wide variety of setups and we didn't want to give unprivileged users the ability to read/write/modify connections that were not created by themselves. At the same time, unprivileged users should be able to connect to new WiFi networks without too much fuss (i.e. without having to enter an admin password). This was the main motivation for the Debian patch [1] to nm-applet back in the days. Nowadays, we have a lot more NetworkManager clients: Cinnamon, GNOME, KDE (plasma-nm) etc all have native NM support. I did a series of tests with an unprivileged users named "test" under Debian trying to connect to a new WiFi network. Here are the results a) GNOME Shell admin prompt, credentials system wide, permissions= b) gnome-control-center no admin prompt, credentials system wide, permissions=user:test:; c) Cinnamon no admin prompt, credentials user wide, permissions=user:test:; d) cinnamon-control-center no admin prompt, credentials system wide, permissions=user:test:; e) nm-applet 1.16.0 no admin prompt, credentials system wide, permissions=user:test:; f) nm-connection-editor 1.16.0 admin prompt, credentials system wide, permissions= g) nm-applet 1.8.24 (with Debian patch [1]) no admin prompt, credentials user wide, permissions=user:test:;
To my understanding, nm-applet and nm-connection-editor don't directly run a polkit agent. Possibly they should, like nmcli does. But that means, they cannot ask for permission, instead they rely on your desktop environment to run a session agent which would prompt you. Possibly that makes sense. Should really every application run its own polkit agent?
h) nm-connection-editor 1.8.24 (with Debian patch [1]) no admin prompt, credentials system wide, permissions=user:test:;
Most interesting would also be the behaviors for nmcli and nmtui.
I think the current situation is unfortunate. Ideally, NM Clients would behave more consistently and provide a better ootb experience for unprivileged users. I find especially a) very unfriendly for users. In a multi-user setup it's unlikely they have an admin password and I think NM clients should just create user-owned connections in that case.
I agree. I see you dropped patch [1] now? Possibly this should be upstream. For nm-connection-editor and gnome-control-center, when you create a new profile it offers you the choice. So in this case it's only important to clear "All users may connect to this network" checkbox, if the user has no permissions. I mean, since the GUI gives you a dialog where you could clear setting yourself, it's less severe (but still annoying).
Whether to store credentials system wide or make them agent owned is another topic. I guess for WiFi connections it makes sense to store them system wide, for VPN connections I would (always) default to make them agent owned.
How secret agents store the secret in the keyring is unfortunately also not consistent and every client reimplements it (differently). e.g. nmcli/nmtui don't support a keyring at all, while plasma-nm and Gnome/GTK GUIs use different wallet backends. Optimally that would be unified too (possibly by moving the functionality to a shared library). Which credential store one wants less tied to the user's permission, but - what kind of secret is this? E.g. I may be fine to put the Company's Wi-Fi secret to the company notebook, but want to encrypt my personal VPN that I setup on such a notebook. But even the distinction Wi-Fi vs. VPN may not be enough. The GUI simply doesn't know. - if you configure the keyring, then autoconnect only works after the user is available to unlock the keyring. That seems quite a restriction, which people might not understand. On the other hand, they users may also dislike to store passwords in plain text, and it may not be obvious to them that that happens. Point is, both values make sense sometimes. It's not clear to me that the default would depend on the policy kit permissions, nor that one default is clearly preferable over the other.
For that reason, I would like your feedback as NetworkManager upstream.
If you write on this list, *you* are upstream!!
Maybe we can come up with a set of recommendations how clients should behave for unprivileged users in a variety of use cases (WiFi, VPN, etc). Once we have that set of rules/recommendations, it would be easier for me to contact the various upstream projects like GNOME, Cinnamon, KDE.
Sounds like a very good idea to me. Thank you for looking into this.
I would also be interested how other distros handle this situation and what there default policy is. I know that Fedora uses --enable-modify-system, which is probably ok if your target audience is a single-user desktop system.
... or if you want that things work well out of the box :) Regarding "single-user"... Which is probably also the common case for debian. I mean, if a user installs Debian for him/herself, then very often it's a single-user machine. Sure there are companies that deployes Debian on thousands of ther their employees notebooks, but these thousands of machines is basically one setup, and the admin can be expected to adjust the configuration. What I mean is, if you take the number of running Debian systems, then maybe many of them are multi user systems. But if you look at how many distinct installations there are (like, a manual installation on my personal notebook or a deloymnet of 1000 company notebooks), I would guess that the majority of installations is for single-user. Anyway, I don't really mind. Shouldn't we have a PolicyKit setup so that certain group get permission (e.g. "wheel", "sudo"), while the rest requires a root password?
This email is already pretty long, so I'll stop here. Looking forward to read your thoughts, Michael [1] https://salsa.debian.org/utopia-team/network-manager-applet/-/blob/debian/master/debian/patches/Allow-creation-of-connections-without-admin-privileges.patch
Attachment:
signature.asc
Description: This is a digitally signed message part