Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 1415760 - gnome-control-center blocks empty 802.1x certificate passwords
gnome-control-center blocks empty 802.1x certificate passwords
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: control-center (Show other bugs)
7.3
x86_64 Unspecified
unspecified Severity high
: rc
: ---
Assigned To: Matthias Clasen
Desktop QE
: Desktop
Depends On: 1433536
Blocks: 1420851 1479818
  Show dependency treegraph
 
Reported: 2017-01-23 11:27 EST by Joe Wright
Modified: 2018-05-17 10:39 EDT (History)
9 users (show)

See Also:
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 08:55:16 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
802.1x and TLS in control-center-3.22.1-2.el7 (261.76 KB, image/png)
2018-02-13 05:12 EST, Pavlin Georgiev
no flags Details
802.1x and TLS in control-center-3.26.1-3.el7 (161.92 KB, image/png)
2018-02-13 05:13 EST, Pavlin Georgiev
no flags Details
802.1x and TLS in control-center (1.06 MB, application/x-gzip)
2018-02-13 06:53 EST, Pavlin Georgiev
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2884921 None None None 2017-01-23 11:47 EST
Red Hat Product Errata RHBA-2018:0770 None None None 2018-04-10 08:57 EDT

  None (edit)
Description Joe Wright 2017-01-23 11:27:54 EST
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?
Comment 3 Bastien Nocera 2017-03-13 09:07:55 EDT
Please test with control-center-3.22.1-2.el7
Comment 5 Matthew Brown 2017-03-17 11:39:54 EDT
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.
Comment 6 Bastien Nocera 2017-03-20 10:29:20 EDT
(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.
Comment 7 Matthew Brown 2017-03-20 18:08:19 EDT
Hello,

The bug report should be number 1433536.  Please let me know if anything is needed further.
Comment 8 Matthew Brown 2017-03-20 18:09:40 EDT
PS: The NetworkManager bug report is an internal bug report, so it will not be accessible publicly.
Comment 15 Pavlin Georgiev 2018-02-13 05:11:00 EST
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.
Comment 16 Pavlin Georgiev 2018-02-13 05:12 EST
Created attachment 1395264 [details]
802.1x and TLS in control-center-3.22.1-2.el7
Comment 17 Pavlin Georgiev 2018-02-13 05:13 EST
Created attachment 1395265 [details]
802.1x and TLS in control-center-3.26.1-3.el7
Comment 18 Pavlin Georgiev 2018-02-13 06:53 EST
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.
Comment 23 errata-xmlrpc 2018-04-10 08:55:16 EDT
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

Note You need to log in before you can comment on or make changes to this bug.