GNOME Bugzilla – Bug 85559
Store proxy password with libsecret
Last modified: 2021-06-09 16:08:52 UTC
HTTP proxy password settings can get exposed if set through network preference capplet. Through this capplet, HTTP proxy user name and password can be specified. This username and password is then stored in "/<user home directory>/.gconf/system/http-proxy/%gconf.xml" in CLEAR TEXT with read/write/exec permission to user only. This settings are then used by the applications like nautilus, gweather stockticker etc. This is an issue in terms of privacy because of the following 1. The root can see the password for user's http proxy settings. 2. If the home directory is exported to other systems and then mounted nfs. In this case others can also see the password. Possible solutions: 1. preliminary thoughts are encrypting the password before storing and decrypting it at the point of retrieval. The fix is likely to affect the network preferences capplet and components which retrieve the information.
Your preliminary thoughts do not solve anything. If you need to pass that password to the proxy then you need a piece of code that takes that password and decrypts it, Rigth? Then ... if there is such piece of code that can take an crypted password and generate a clean password, How are you going to avoid root running that piece of code and decrypting it?
I understand that root can still have access to password. While storing the password by user through capplet, user might not be aware that the password is getting stored in clear text and can be seen by root. At least user could be warned that the password information being stored can be seen by others. This is not being done at present. In case, user is not willing to disclose his/her http proxy password to anybody and is not willing to store it through network capplet because of privacy issues, other applications(like nautilus etc) should prompt for password. In this case at least user would know that private information can be seen by others and have an option to not to store in his/her home directory.
I am not saying that this could not happen, all I am saying is that encrypting and decrypting the password changes nothing.
Worse than that, root can see/steal ~/.ssh/identity and thus steal your identity - is it even me that is typing this ? ;-)
The issue was discussed in the community through desktop-devel-list. The link to the thread is http://mail.gnome.org/archives/desktop-devel-list/2002-July/msg00515.html There is a consensus to at least encrypt the password and store it into the disk. A patch to this will be provided soon. Along with it, password prompting feature is currently being considered.
No intermediate solution of encrypt and save to disk patch will be provided to the community.
Verified on HEAD as well. Can't we use the shiny new keyring manager for this kind of pwd magic? regs, Chris
*** Bug 118168 has been marked as a duplicate of this bug. ***
*** Bug 321602 has been marked as a duplicate of this bug. ***
*** Bug 379687 has been marked as a duplicate of this bug. ***
Since trivial obfuscation (which doesn't increase security at all) definitely won't happen, repurposing this bug as a feature request for storing the proxy password in gnome-keyring instead.
Aren't HTTP proxy passwords sent out in clear text over the network anyway?
Dan, Stef, is this something we can implement? What about applications relying on libproxy directly?
We could definitely have glib-networking pull the password out of the secret store rather than gsettings. Apps using libproxy would lose until libproxy got updated to use libsecret and distros got updated to use the new libproxy... (Hm... we should tweak the libproxy gnome plugin to try to just use GProxyResolverGnome...)
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new bug report at https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/ Thank you for your understanding and your help.