Bug 1415760
| Summary: | gnome-control-center blocks empty 802.1x certificate passwords | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Joe Wright <jwright> | ||||||||
| Component: | control-center | Assignee: | Matthias Clasen <mclasen> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> | ||||||||
| Severity: | high | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 7.3 | CC: | alanm, jwright, mabrown, mclasen, mkolbas, pgeorgie, rmanes, tpelka, vbenes | ||||||||
| Target Milestone: | rc | Keywords: | Desktop | ||||||||
| Target Release: | --- | ||||||||||
| Hardware: | x86_64 | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | control-center-3.26.1-3.el7 | Doc Type: | If docs needed, set a value | ||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2018-04-10 12:55:16 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Bug Depends On: | 1433536 | ||||||||||
| Bug Blocks: | 1420851, 1479818 | ||||||||||
| Attachments: |
|
||||||||||
Please test with control-center-3.22.1-2.el7 Hello, It looks like the same issue happens in nmcli as well: [user@rhel7 ~]$ nmcli connection modify dot1x 802-1x.eap tls 802-1x.ca-cert /etc/pki/CA/cacert.pem 802-1x.client-cert /home/user/user.pem 802-1x.identity test Error: Failed to modify connection 'dot1x': 802-1x.private-key: property is missing By contrast, openssl is able to open the same private key given to nmlci just fine without a password. For comparison, here is openssl opening the original password-protected key with a password as well: [user@rhel7 ~]$ openssl rsa -in /home/user/private.pem -text > /dev/null Enter pass phrase for /home/user/private.pem: writing RSA key [user@rhel7 ~]$ openssl rsa -in /home/user/private-nopass.pem -text > /dev/null writing RSA key While there is still the GUI issue that this bug report was opened for, I will file a bug in NetworkManager to make sure that NetworkManager itself accepts passwordless private keys. (In reply to Matthew Brown from comment #5) <snip> > While there is still the GUI issue that this bug report was opened for, I > will file a bug in NetworkManager to make sure that NetworkManager itself > accepts passwordless private keys. Let us know the bug number, as we can't fix this bug without NetworkManager actually accepting the certificate. I guess it would be pretty easy to see whether a password is required or not, so we don't ask for a password if the certificate doesn't have one. Hello, The bug report should be number 1433536. Please let me know if anything is needed further. PS: The NetworkManager bug report is an internal bug report, so it will not be accessible publicly. Component version:
control-center-3.22.1-2.el7
TEST SETUP 1
On a VM under RHEL-7.4-20170711.0.
Download the build of control-center with the bug from Brew server:
brew download-build control-center-3.22.1-2.el7 --arch $(uname -p)
Downgrade the package control-center from 3.22.2-5 to 3.22.1-2.
TEST PROCEDURE 1
1. Start gnome-control-center.
2. Select a network interface.
3. Create a new profile using 802.1x and authentication TLS.
The bug appears. Private key password is obligatory.
TEST SETUP 2
On a VM under RHEL-7.5-20171130.0.
Download the build of control-center with the fix from Brew server:
brew download-build control-center-3.26.1-3.el7 --arch $(uname -p)
Downgrade control-center from 3.26.2-2 to 3.26.1-3.
TEST PROCEDURE 2
1. Start gnome-control-center.
2. Select a network interface.
3. Create a new profile using 802.1x and authentication TLS.
The bug appears. Private key password can be left empty, not required.
RESULTS
Upgrading the component: control-center
from: 3.22.1-2.el7
to: 3.26.1-3.el7
has fixed the bug.
Created attachment 1395264 [details]
802.1x and TLS in control-center-3.22.1-2.el7
Created attachment 1395265 [details]
802.1x and TLS in control-center-3.26.1-3.el7
Created attachment 1395295 [details]
802.1x and TLS in control-center
I have prepared testing environment for 802.1x and TLS having:
Security certificates:
- CA, server certificate, server private key
- client certificate, client private key
802.1x authenticator:
hostapd
In control-center-3.26.1-3.el7 you can create network profile with 802.1x and TLS without specifying private key password.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:0770 |
Description of problem: - gnome-control-center does not allow empty passwords for 802.1x certs, even though wpa_supplicant normally does (with a warning message) Version-Release number of selected component (if applicable): - current How reproducible: - Attempt to configure and use 802.1x certs with no password via GUI Steps to Reproduce: 1. 2. 3. Actual results: Expected results: - should mirror CLI configuration behaviors Additional info: Although I agree it's probably a bad idea to have a key without a password, it should still technically be possible and the GUI appears to prevent this. This code seems to be the culprit (from upstream): 54 static gboolean 55 validate (EAPMethod *parent, GError **error) 56 { - - - - - - - - - 8< - - - - - - - - - 92 if (!password || !strlen (password)) { 93 widget_set_error (widget); 94 if (ret) { 95 g_set_error_literal (error, NMA_ERROR, NMA_ERROR_GENERIC, _("invalid EAP-TLS password: missing")); 96 ret = FALSE; 97 } Assuming I am right, this should be fairly easy to fix in the GUI upstream and then pull back into RHEL, but I don't have an 802.1x environment easily available for me to test a patch. If I launch: # gnome-control-center network And try, the debug output provides the following: ** (gnome-control-center:10063): CRITICAL **: eap_method_validate_filepicker: assertion 'strlen (password)' failed So A) this looks to be an intentional limitation perhaps? and B) we check the length of the password to be non-null before we even try, which happens here: 221 gboolean 222 eap_method_validate_filepicker (GtkBuilder *builder, 223 const char *name, 224 guint32 item_type, 225 const char *password, 226 NMSetting8021xCKFormat *out_format, 227 GError **error) 228 { 229 GtkWidget *widget; 230 char *filename; 231 NMSetting8021x *setting; 232 gboolean success = TRUE; 233 234 if (item_type == TYPE_PRIVATE_KEY) { 235 if (!password || *password == '\0') 236 success = FALSE; <------------------ 237 } - - - - - - - - - 8< - - - - - - - - - 282 return success; 283 } Additional concerns: - Will allowing(fixing) this break STIG or other gov't certifications? - Allowing blank passwords here is generally a bad idea. Was the intent in this design to explicitly block this behavior? If so, would it be reasonable to write a gconf key that, when enabled, makes it mimic the expected CLI behavior?