Bug 1358881
Summary: | pam access.conf file misparses group names that contain "@" characters | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | James Ralston <ralston> | ||||
Component: | pam | Assignee: | Tomas Mraz <tmraz> | ||||
Status: | CLOSED ERRATA | QA Contact: | Dalibor Pospíšil <dapospis> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | high | ||||||
Version: | 7.2 | CC: | dapospis, ekeck, kludhwan, mgrepl, mthacker, pkis, qe-baseos-security, tmraz | ||||
Target Milestone: | rc | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | pam-1.1.8-19.el7 | Doc Type: | If docs needed, set a value | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | |||||||
: | 1359303 (view as bug list) | Environment: | |||||
Last Closed: | 2018-04-10 11:35:33 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: | |||||||
Bug Blocks: | 1359303, 1420851 | ||||||
Attachments: |
|
Created attachment 1182636 [details]
correct behavior of user_match() to honor (group) constructs
I think the best way to address this is to check for a '(group)' construct first, before attempting to parse for '@' characters.
I agree, however to properly prioritize the issue could you please report it also through regular support channels? http://www.redhat.com/support *** Bug 1358880 has been marked as a duplicate of this bug. *** Cross-filed as a support case. (Sorry about the dupe—Bugzilla gave me an internal server error when I first tried to submit the bug, and I didn't think to check whether it actually succeeded despite the error.) Also, RHEL6 has the exact same bug, so it should be squashed there, too. Should I clone this bug for RHEL6? Please, just report that via the support case. 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:0718 |
Description of problem: The pam_access.so module reads access rules from the access.conf file. When parsing each whitespace-separated strings in the user/group field in access.conf, pam_access checks for user@host patterns and @netgroup patterns before checking whether the first and last characters are '(' and ')', respectively. This is an error, for multiple reasons. First, the access.conf(5) man page states: > To differentiate user entries from group entries, group entries should be > written with brackets, e.g. (group). This implies that using (group) overrides any other interpretation of the string "group" except a group name, but the behavior of the code does not honor this override. But more importantly, it makes it IMPOSSIBLE to specify a group that contains an '@' character. E.g.: + : (linux-managers) : ALL Because the parsing checks for '@' characters before looking for the '(group)' override, the '(linux-managers)' string is parsed as a user@hostname, instead of as a group: pam_access(sshd:account): login_access: user=someuser, from=somehost.example.org, file=/etc/security/access.conf pam_access(sshd:account): line 16: + : (linux-managers) : ALL pam_access(sshd:account): list_match: list= (linux-managers) , item=someuser pam_access(sshd:account): user_match: tok=(linux-managers), item=someuser pam_access(sshd:account): user_match: tok=(linux-managers, item=someuser pam_access(sshd:account): string_match: tok=(linux-managers, item=someuser pam_access(sshd:account): user_match=0, "someuser" Not being able to use '@' characters in group names breaks sites that are using sssd(8) and use the sss database for user and group lookups. While sites that use only a single domain can leave off the @domain part, in the case where sssd(8) is using multiple domains, users and groups *MUST* be fully-qualified as user@domain and group@domain, respectively, to disambiguate which domain is being referred to. Fortunately, the fix for this bug is very simple: change the user_match() function in modules/pam_access/pam_access.c to test for the '(group)' construct first, before attempting to split on '@' characters. I'll attach a patch momentarily. Version-Release number of selected component (if applicable): pam-1.1.8-12.el7_1.1.x86_64 How reproducible: On an sssd-enabled system, attempt to grant access via a fully-qualified group@domain entry in /etc/security/access.conf.