GNOME Bugzilla – Bug 646187
Connecting to (new) wireless network requires polkit authentication
Last modified: 2020-11-12 14:28:37 UTC
When I connect to a wireless network that I hadn't used before, I'm being asked for polkit authentication. This is because we try to create this network connection as available for all users. The polkit authentication is really painful here. And I really think it makes no sense to create system-wide by default connections for the wireless networks I use: I might not want other users on my computer to use those. Note: it could be a NM issue, not sure.
(In reply to comment #0) > Note: it could be a NM issue, not sure. It is both, in the sense that really should be fixed in NM, but it can be fixed in the shell as well, just by making all connections we create private to the user.
(In reply to comment #0) > When I connect to a wireless network that I hadn't used before, I'm being asked > for polkit authentication. This is because we try to create this network > connection as available for all users. > > The polkit authentication is really painful here. And I really think it makes > no sense to create system-wide by default connections for the wireless networks > I use: I might not want other users on my computer to use those. > > Note: it could be a NM issue, not sure. There are no more "per user" connections starting with nm-0.9
(In reply to comment #2) > There are no more "per user" connections starting with nm-0.9 The setting is still available in nm-connection-editor, though.
being available for all users is different from being stored per-user...
Created attachment 184780 [details] [review] NetworkMenu: create private connections by default Add the "permissions" setting to the connections we create, so that polkit authentication is not needed and the connection is not available to other users. Not yet good to commit because nm_setting_connection_add_permission is missing (allow-none) on the last parameter (which must be NULL at all times).
This was discussed at *great* length on gnome-os recently. I believe what was decided that is that the correct approach on a typical system is to simply configure policykit so that normal users can edit system connections. Per-user connections work badly with fast user switching for one thing.
Hrm. I see the point. I'm worried that, at least in openSUSE, the security team will likely not accept such a default policy, and I wonder if other downstreams will face the same issue.
But will a user be able to create a private connection without authenticating? It would be sad that clicking on a new WiFi asks for authentication and completely fails if user doesn't have the required rights. Maybe the solution would be to check non-interactively for PolicyKit authorization, and if it fails, fallback to private connection instead of asking for password. That would work for all distributor choices.
(In reply to comment #8) > But will a user be able to create a private connection without authenticating? > It would be sad that clicking on a new WiFi asks for authentication and > completely fails if user doesn't have the required rights. > > Maybe the solution would be to check non-interactively for PolicyKit > authorization, and if it fails, fallback to private connection instead of > asking for password. That would work for all distributor choices. NetworkManager already does that. Adding a private connection for the user and adding a shared one are distinct PolicyKit actions. Then, PolicyKit authority automatically skips the polkit agent is policy is "no", at which point NetworkManager will just return failure to the shell, without asking nm-applet for network keys or any other user interaction.
(In reply to comment #9) > NetworkManager already does that. Adding a private connection for the user and > adding a shared one are distinct PolicyKit actions. Then, PolicyKit authority > automatically skips the polkit agent is policy is "no", at which point > NetworkManager will just return failure to the shell, without asking nm-applet > for network keys or any other user interaction. Yes, but I'm not talking about the "no" case, but about the "auth_admin" or "auth_admin_keep" one, which is likely to be chosen by a few distributions or admins anyway. In this case, the PK authority won't return, but will trigger an auth dialog, which the user will have to Cancel if he isn't an admin. And that non-admin user won't have any (simple) solution to connect to that new WiFi network. My suggestion was to run polkit_authority_check_authorization() without the POLKIT_CHECK_AUTHORIZATION_FLAGS_ALLOW_USER_INTERACTION flag (from the Shell), and if it fails, automatically fallback to creating a private connection.
(In reply to comment #10) > (In reply to comment #9) > > NetworkManager already does that. Adding a private connection for the user and > > adding a shared one are distinct PolicyKit actions. Then, PolicyKit authority > > automatically skips the polkit agent is policy is "no", at which point > > NetworkManager will just return failure to the shell, without asking nm-applet > > for network keys or any other user interaction. > Yes, but I'm not talking about the "no" case, but about the "auth_admin" or > "auth_admin_keep" one, which is likely to be chosen by a few distributions or > admins anyway. In this case, the PK authority won't return, but will trigger an > auth dialog, which the user will have to Cancel if he isn't an admin. And that > non-admin user won't have any (simple) solution to connect to that new WiFi > network. > > My suggestion was to run polkit_authority_check_authorization() without the > POLKIT_CHECK_AUTHORIZATION_FLAGS_ALLOW_USER_INTERACTION flag (from the Shell), > and if it fails, automatically fallback to creating a private connection. Ah, you meant when the user is not an administrator. It would make sense, yes. I'll write it when this is definitively approved.
Another reason it's a bad idea to create a system-wide connection is that the WPA password might be for one user only. A typical example for me is the Novell wireless network, for which authentication is really per-employee, so I really wouldn't want anybody else on my computer to be able to use my credentials for that. (And yes, I'm talking about a wifi connection, not vpn)
Better discussed with NetworkManager, since this is all a result of NM polkit policy, not gnome-shell.
So there's a few issues here which necessitated the PK stuff: 1) The secrets for connections can either be system-wide (stored in /etc and thus requiring PK authentication), or user owned (ie stored in gnome-keyring in the user's session) 2) By default in nm-applet all secrets *except* VPN secrets are created as system-wide; VPN secrets are user owned 3) We need some good default policy on what secrets should be system-wide and which should be user owned 4) How do we switch secrets, if the user for some reason wants to do that? How do you tell whatever connection editor that you want the secrets in your user session instead of system-wide? About that only thing I can think of is a right-click menu on the secret's GtkEntry in nm-connection-editor, but that's kinda horrible; this isn't something that most people need to do, and a sensible default policy makes it irrelevant for most users already anyway But again, we can't save *anything* to a 'system-wide' connection without going through Polkit authentication for security reasons. But again, we may want a system-wide connection, but user-owned secrets. For example, the sysadmin sets up an 802.1x/WPA Enterprise connection in /etc for *all* users and deploys it to a large number of machines. This connection includes basic stuff like the company CA certificate and SSID and such, but the password is user-specific, so the sysadmin sets the password flags to be "agent-owned". In that case we shouldn't be asking for Polkit authentication because the user doesn't need to change any connection properties, and the password is user-owned. But there's a pretty good argument to be made that unencrypted, WEP, and WPA-PSK connections should be system-wide by default, with passwords stored system-wide, because there's nothing at all personal about them. WPA-Enterprise and VPN connections are clearly usually more personal. But unless your WEP/WPA-PSK AP is used only by you, it's a system wide setting just like it is on Mac OS X and Windows.
FWIW because the SUSE security team has been mentioned ... On behalf of that team I agree with comment #14. That's exactly the behavior I've wanted for years.
How much of comment #14 is already implemented in NM 0.9 atm? Saving credentials in a per user agent is missing, right? AFAICS the credentials are either stored in plain text in /etc (without warning!) or need to be always entered when connecting. Also, activating a connection that prompts for the password requires polkit authentiation. I suppose that's not intended as entering the password doesn't actually modify the connection but rather completes intentionally missing information.
Created attachment 206673 [details] [review] gsettings to switch default connection mode This tentative nm-applet patch is for the "auth_admin_keep" and "auth_admin" cases which will prompt the authentication dialog when the user tries to create a new connection, and it may make wifi unusable if the user isn't the administrator. The patch adds a gsettings key to control the default connection mode and makes nm-applet/gnome-shell more flexible to meet different distributions' polkit policies.
(In reply to comment #17) > Created an attachment (id=206673) [details] [review] > gsettings to switch default connection mode > > This tentative nm-applet patch is for the "auth_admin_keep" and "auth_admin" > cases which will prompt the authentication dialog when the user tries to create > a new connection, and it may make wifi unusable if the user isn't the > administrator. The patch adds a gsettings key to control the default connection > mode and makes nm-applet/gnome-shell more flexible to meet different > distributions' polkit policies. As I said in comment #8, I don't think you need a new setting for that, just check *uninteractively* whether the user would be allowed to create a system-wide connection or not, and fall back to the solution that works without prompting an auth dialog. This will automatically adapt to distributors' PolicyKit rules - and even to local changes done by administrators. Generally, adding new settings to the Shell has not been very welcome, so it will even be simpler to get this committed if you don't. That's my two cents. ;-)
Created attachment 206963 [details] [review] quick hack for nm-applet to check polkit authorization Just applied this patch to a "auth_admin_keep" system, and nm-applet created new private connections by default without prompting any authentication dialog. Love this idea :-)
Ok, so if checking polkit is the way to go, here is the updated and rebased patch for gnome-shell (plus a small patch to gjs for getpid() and getuid())
Created attachment 206987 [details] [review] system: add getpid(), getuid(), getgid() These functions are useful sometimes (for example when building a PolkitSubject), and have no equivalent in GLib, therefore it's appropriate to place them in the system module.
Created attachment 206988 [details] [review] NetworkMenu: create private connections if the user is not authorized Check polkit setting at startup and add, if needed, the "permissions" setting to the connections we create, so that polkit authentication is never needed. The connection is thus only available to other users if the system administrator decides so.
Created attachment 207608 [details] [review] the patch for gnome-control-center
Created attachment 208099 [details] [review] nm-applet: create private connections if the user is not authorized Clean up my previous quick hack.
So, what happened with this bug? Are the patch good to go in, or is the expected interaction different, or...?
Good question - lets see if we can get some review/opinion on this
Review of attachment 206987 [details] [review]: Do you really have to metaprogram this? It's possibly the smallest JS function hook you could write.
Review of attachment 206988 [details] [review]: ::: js/ui/status/network.js @@ +1555,3 @@ + // Check if newly created connections should be private or not + this._client._privateConnections = true; Do we really need the expando properties here? @@ +1559,3 @@ + let subject = new Polkit.UnixProcess({ pid: System.getpid(), uid: System.getuid() }); + let authResult = authority.check_authorization_sync(subject, + "org.freedesktop.NetworkManager.settings.modify.system", Single quotes for non-translatable strings. @@ +1564,3 @@ + null /* cancellable */); + if (authResult) + this._client._privateConnections = ! authResult.get_is_authorized(); No space in between ! and authResult.
(In reply to comment #25) > So, what happened with this bug? > Are the patch good to go in, or is the expected interaction different, or...? dcbw suggested in comment 14 that any wireless connection that doesn't have per-user passwords should be system-wide (by default), and only stuff like WPA Enterprise should default to per-user (which it should do even if you have permission to create a system-wide connection). So, assuming we wanted that behavior, these patches aren't right. (IMHO, on a desktop/laptop machine, the default should be that admins can edit system network connections without a password.)
(In reply to comment #29) > (In reply to comment #25) > > So, what happened with this bug? > > Are the patch good to go in, or is the expected interaction different, or...? > > dcbw suggested in comment 14 that any wireless connection that doesn't have > per-user passwords should be system-wide (by default), and only stuff like WPA > Enterprise should default to per-user (which it should do even if you have > permission to create a system-wide connection). So, assuming we wanted that > behavior, these patches aren't right. > > (IMHO, on a desktop/laptop machine, the default should be that admins can edit > system network connections without a password.) "Stuff like" or exactly only WPA enterprise? Because if the latter, the bug should be reassigned to network-manager-applet, which handles creating such connections through libnm-gtk (and the shell continues to create only system wide connections) (gnome-shell never creates wired 802.1x, vpn or wwan directly, fwiw)
(In reply to comment #29) > (In reply to comment #25) > > So, what happened with this bug? > > Are the patch good to go in, or is the expected interaction different, or...? > > dcbw suggested in comment 14 that any wireless connection that doesn't have > per-user passwords should be system-wide (by default), and only stuff like WPA > Enterprise should default to per-user (which it should do even if you have > permission to create a system-wide connection). So, assuming we wanted that > behavior, these patches aren't right. Well, those patches are really intended to fix the "I need polkit authentication to create system-wide connections" issues. Which is highly annoying when it's the case on your computer. If polkit authentication is not needed, then it's fine to have system-wide connections, but otherwise, it's just a big pain.
Created attachment 213055 [details] [review] system: add getpid(), getuid(), getgid() These functions are useful sometimes (for example when building a PolkitSubject), and have no equivalent in GLib, therefore it's appropriate to place them in the system module. Updating the patch to address comments, even if definitive design is not clear yet. Btw, the system module is one thing that would surely benefit from GjsPrivate (bug 675018)
Created attachment 213056 [details] [review] NetworkMenu: create private connections if the user is not authorized Check polkit setting at startup and add, if needed, the "permissions" setting to the connections we create, so that polkit authentication is never needed. The connection is thus only available to other users if the system administrator decides so.
Review of attachment 213055 [details] [review]: Sure.
How is the progress on this bug? I see the one for GJS has been merged; there are at least three more bugs mentioned in this bug, applying on: * gnome-control-center * gnome-shell * nm-applet Are those patches fine as well from an upstream perspective? Will they be merged during the 3.5 merge window?
The gnome-shell patch will need to be rebased, at least.
Created attachment 216879 [details] [review] NetworkMenu: create private connections if the user is not authorized Check polkit setting at startup and add, if needed, the "permissions" setting to the connections we create, so that polkit authentication is never needed. The connection is thus only available to other users if the system administrator decides so. Rebased.
The patches from here seem no longer to apply to gnome-control-center. Is there any chance to merge all this work for 3.6?
network-manager-applet-0.9.6.2 also seems to have some re-organization, causing the patches no longer to apply on it.
Created attachment 221101 [details] [review] nm-applet: create private connections if the user is not authorized Rebased the nm-applet patch to fit the current git head.
Comment on attachment 221101 [details] [review] nm-applet: create private connections if the user is not authorized Sorry I pull the wrong git tree. Obsolete the patch.
Created attachment 221103 [details] [review] Rebased nm-applet-private-connection.patch; all work basedon Gary's original patch
Created attachment 224311 [details] [review] gnome-control-center patch Rebased the patch for g-c-c; I'm not able to test it right now :/
So, are we doing anything with this bug or not? The only committed patch just got reverted in gjs...
(In reply to comment #44) > So, are we doing anything with this bug or not? > The only committed patch just got reverted in gjs... Well, that's because GCredentials has API for it already, so just use that instead.
Created attachment 233656 [details] [review] Updated patch for nm-applet The OpenSUSE patches don’t put secrets in the keyring, which is another problem of the “push everything to the system” policy. This is the patch we use in Debian. In addition to using a different policy depending on the connection type, we also push secrets to the keyring.
Created attachment 233657 [details] [review] Updated patch for control-center This is the same stuff for the control-center.
Created attachment 233659 [details] [review] Updated patch for gnome-shell Finally the same for gnome-shell.
Note that they are all based on 3.4 for now since this is what is going in wheezy. We’ll provide a 3.6 version sometime.
Created attachment 237649 [details] [review] nm-applet patch Further working on Dominique and Gary's patches; I've worked on it a little more to make sure one could "properly" handle the cases where the polkit authorization result is "auth_admin" -- in this particular case, I think you actually want to give the user a chance to auth rather fallback straight to user-owned connections? Unless I'm misunderstanding the code.. Furthermore, in testing locally I noticed that the connection editor wouldn't properly bring up the Edit / Remove buttons as sensitive for these user-owned connections. ... Also rebased on current nm-applet master.
(In reply to comment #50) > Further working on Dominique and Gary's patches; I've worked on it a little > more to make sure one could "properly" handle the cases where the polkit > authorization result is "auth_admin" -- in this particular case, I think you > actually want to give the user a chance to auth rather fallback straight to > user-owned connections? Unless I'm misunderstanding the code.. I’m afraid you are misunderstanding the code. If the authorization result is “auth_admin”, the user will be asked for the root password even if she just wants to connect to a WPA2 network she has the passphrase of. In this case you definitely want to fallback to a user-owned connection.
Indeed, makes sense on Debian, where the policy will usually be auth_admin. Thanks!
Is there still interest to be able to connect to a protected WLAN without root passwords? The patches, obviously, no longer apply on gnome 3.9.91.
Yes, there is still interest.
(In reply to comment #53) > Is there still interest to be able to connect to a protected WLAN without root > passwords? > > The patches, obviously, no longer apply on gnome 3.9.91. I'll update the patches anyway for Debian and obviously we would like to see them merged upstream. Cheers, Michael
Is there still anything needed in NetworkManager daemon itself? If not, please reassign to the respective product/component.
There is no patch for NetworkManager but patches for network-manager-applet, gnome-control-center, and gnome-shell. I'm not sure which component should be assigned for this bug.
Created attachment 256609 [details] [review] nm-applet patch rebased on 0.9.8.4
Created attachment 256610 [details] [review] gnome-control-center patch rebased on 3.10.0.1
Created attachment 256611 [details] [review] gnome-shell patch rebaesd on 3.10.0.1
Gary, regarding your three patches, I think if a connection is marked as user-owned, the secrets should also be agent-owned, i.e. stored in the user session. That's what the Debian patches do, which we've been shipping for nm-applet, gnome-shell and gnome-control-center for a while now and apparently users are happy with the current setup, since the bug reports regarding that issue stopped as soon as we applied them. For reference, these are the current versions: -nm-applet http://anonscm.debian.org/gitweb/?p=pkg-utopia/network-manager-applet.git;a=blob;f=debian/patches/11-user-connections.patch;hb=HEAD - gnome-control-center http://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/gnome-control-center/debian/patches/11_network_user_connections.patch?view=markup - gnome-shell http://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/gnome-shell/debian/patches/28_network_user_connections.patch?view=markup The policy is roughly this: Set passwords as agent-owned when they need to, to allow users without root permissions to easily configure their connections. + CDMA and GSM connections are always user-owned. + WEP/WPA connections are system-owned if user has the permissions (with NM’s config, that is netdev or sudo membership in Debian), user-owned otherwise. The password is stored in the keyring for WPA, not for WEP. + WiMax / Wired connections are always system-owned.
(In reply to comment #61) > The policy is roughly this: > Set passwords as > agent-owned when they need to, to allow users without root > permissions to easily configure their connections. > + CDMA and GSM connections are always user-owned. > + WEP/WPA connections are system-owned if user has the permissions > (with NM’s config, that is netdev or sudo membership in Debian), user-owned > otherwise. The password is stored in the keyring for WPA, not for > WEP. ^ small correction, WEP keys are also stored in the keyring if the connection is user user-owned. > + WiMax / Wired connections are always system-owned.
Moving from Wi-Fi to nm-applet even though gnome-shell is taken into account as well.
(In reply to comment #61) > Gary, regarding your three patches, I think if a connection is marked as > user-owned, the secrets should also be agent-owned, i.e. stored in the user > session. > Indeed, the secrets shall be stored in the keyring for the user-owned connections. I'll amend the patches based on your patches.
I just noticed that the links were broken, so here we go - nm-applet http://anonscm.debian.org/gitweb/?p=pkg-utopia/network-manager-applet.git;a=blob;f=debian/patches/0001-Allow-to-create-connections-without-admin-privileges.patch;h=75b0ae49b87e2460fd507ab6fa60cb27f835501a;hb=HEAD - gnome-shell http://anonscm.debian.org/viewvc/pkg-gnome/tags/gnome-shell/3.4.2-7/debian/patches/28_network_user_connections.patch?view=markup - gnome-control-center http://anonscm.debian.org/viewvc/pkg-gnome/tags/gnome-control-center/1%3A3.4.3.1-2/debian/patches/11_network_user_connections.patch?view=markup If there is interest, I'm willing to forward port them (again) to newer versions.
*** Bug 660392 has been marked as a duplicate of this bug. ***
I think I'd just skip the permissions check and make non-open WiFi, VPN, mobile broadband, Bluetooth, PPPoE, and ADSL connections all private using permissions and password flags. By changing behavior based on the permissions applicable at that time (which can change) we now have less deterministic behavior that's harder to debug and explain to users. Thoughts on that? The downside of doing this is that these connections are no longer available before login, since they are private to the user, and that user has no session until login. Also, when Fast User Switching, the private connection will still be running until the user that started it logs out. However, any other user will not be able to see details of that on-disk connection or read any passwords, as we'd expect. The switched-to user will also not be able to disconnect the device or start a different connection on the device, because the running connection is private to the first user. (they can however become root and do it, eg "sudo nmcli dev disconnect eth0") It's important to note these tradeoffs if most connections were to be user-private by default.
What happened to the idea of making connections available to everyone but store personal secrets in the user agent?
(In reply to comment #68) > What happened to the idea of making connections available to everyone but store > personal secrets in the user agent? You can do that, but if the users don't trust each other, then they shouldn't be using each other's connections. (Eg, in the future, connections may have associated proxy settings.) Also, there's no real advantage to doing it that way; difficult-to-configure connection types (WPA Enterprise, VPNs, 802.11x) almost always have a username as part of the configuration, so you wouldn't want to share those connections anyway. And easy-to-configure connection types are easy to configure (ie, just click on a wifi network name in the list), so sharing them doesn't really help you at all (if they don't also come with shared passwords).
Comment on attachment 256610 [details] [review] gnome-control-center patch rebased on 3.10.0.1 Marking gnome-control-center patch as obsolete, we already have code for that in 3.16 and later.
Comment on attachment 224311 [details] [review] gnome-control-center patch Another obsolete control-center patch. Not sure how the submitter expected the gnome-control-center maintainers to find this patch...
Comment on attachment 233657 [details] [review] Updated patch for control-center And the last obsolete control-center patch.
Comment on attachment 256611 [details] [review] gnome-shell patch rebaesd on 3.10.0.1 Doesn't apply cleanly anymore. Please make sure to post gnome-shell patches in gnome-shell bugs in the future.
Duplicate: https://gitlab.gnome.org/GNOME/network-manager-applet/issues/18
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).