RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1819259 - NetworkManager does not adhere to security note in nm-settings-keyfile man page
Summary: NetworkManager does not adhere to security note in nm-settings-keyfile man page
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: NetworkManager
Version: 8.4
Hardware: x86_64
OS: Linux
low
low
Target Milestone: rc
: 8.0
Assignee: Thomas Haller
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-03-31 15:11 UTC by mcolombo
Modified: 2023-12-15 17:35 UTC (History)
11 users (show)

Fixed In Version: NetworkManager-1.25.1-1.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-04 01:49:27 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:4499 0 None None None 2020-11-04 01:50:03 UTC

Description mcolombo 2020-03-31 15:11:49 UTC
Description of problem:
man nm-settings-keyfile states the following

"For security, it will ignore files that are readable or writable by any user or group other than 'root' since private keys and passphrases may be stored in plaintext inside the file."

However if you create /etc/NetworkManager/system-connections/* and make its mode 640, ownership root:root it will be ignored by NetworkManager

Version-Release number of selected component (if applicable):
This behaviour is present in RHEL 7/8 and fc31

How reproducible:
Every time

Steps to Reproduce:
1. create a NM connection via keyfile in /etc/NetworkManager/system-connections/*
2. Make sure ownership is root:root
3. set mode to 640
4. restart NetworkManager

Actual results:
File is ignored

Expected results:
File be read and settings applied

Additional info:
Looking at the NM source it looks like it's checking against the umask of 0077

gboolean
nms_keyfile_utils_check_file_permissions_stat (NMSKeyfileFiletype filetype,
                                               const struct stat *st,
                                               GError **error)
{
        g_return_val_if_fail (st, FALSE);

        if (filetype == NMS_KEYFILE_FILETYPE_KEYFILE) {
                if (!S_ISREG (st->st_mode)) {
                        g_set_error_literal (error, NM_SETTINGS_ERROR, NM_SETTINGS_ERROR_INVALID_CONNECTION,
                                             "file is not a regular file");
                        return FALSE;
                }
        } else if (filetype == NMS_KEYFILE_FILETYPE_NMMETA) {
                if (   !S_ISLNK (st->st_mode)
                    && !S_ISREG (st->st_mode)) {
                        g_set_error_literal (error, NM_SETTINGS_ERROR, NM_SETTINGS_ERROR_INVALID_CONNECTION,
                                             "file is neither a symlink nor a regular file");
                        return FALSE;
                }
        } else
                g_return_val_if_reached (FALSE);

        if (!NM_FLAGS_HAS (nm_utils_get_testing (), NM_UTILS_TEST_NO_KEYFILE_OWNER_CHECK)) {
                if (st->st_uid != 0) {
                        g_set_error (error, NM_SETTINGS_ERROR, NM_SETTINGS_ERROR_INVALID_CONNECTION,
                                     "File owner (%lld) is insecure",
                                     (long long) st->st_uid);
                        return FALSE;
                }

                if (   S_ISREG (st->st_mode)
                    && (st->st_mode & 0077)) {        <<<<<------   
                        g_set_error (error, NM_SETTINGS_ERROR, NM_SETTINGS_ERROR_INVALID_CONNECTION,
                                     "File permissions (%03o) are insecure",
                                     st->st_mode);
                        return FALSE;
                }
        }

        return TRUE;
}



The code could be fixed to do what the man page states by adding in an additional check for st->st_gid != 0 to make sure the group is set to root, and then the 0077 could be changed to 0007 to allow 640 to work.

Comment 1 Thomas Haller 2020-03-31 17:52:56 UTC
I guess, the manual page just wrongly worded the case. I don't think anybody ever intended that the "root" group may be allowed to access the file.

If we keep the current behavior and clarify the manual page, is that OK? Or do you actually request that the file may be accessible to the root group?

Comment 2 mcolombo 2020-03-31 19:18:50 UTC
Thomas, 

That should be fine as that was the customer's original suggestion. It was my suggestion to change NM to better match the behaviour described in the man page, but I have no issue with the man page being updated to better match the actual behaviour. 



- Colombo

Comment 8 errata-xmlrpc 2020-11-04 01:49:27 UTC
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 (NetworkManager bug fix and enhancement update), 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-2020:4499


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