Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1358881 - pam access.conf file misparses group names that contain "@" characters
pam access.conf file misparses group names that contain "@" characters
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pam (Show other bugs)
7.2
Unspecified Unspecified
high Severity medium
: rc
: ---
Assigned To: Tomas Mraz
Dalibor Pospíšil
:
: 1358880 (view as bug list)
Depends On:
Blocks: 1420851 1359303
  Show dependency treegraph
 
Reported: 2016-07-21 13:11 EDT by James Ralston
Modified: 2018-04-10 07:36 EDT (History)
8 users (show)

See Also:
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 07:35:33 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)
correct behavior of user_match() to honor (group) constructs (1.08 KB, patch)
2016-07-21 13:32 EDT, James Ralston
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0718 None None None 2018-04-10 07:36 EDT

  None (edit)
Description James Ralston 2016-07-21 13:11:31 EDT
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@example.org) : ALL

Because the parsing checks for '@' characters before looking for the '(group)' override, the '(linux-managers@example.org)' 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@example.org)  :  ALL
pam_access(sshd:account): list_match: list= (linux-managers@example.org) , item=someuser
pam_access(sshd:account): user_match: tok=(linux-managers@example.org), 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.
Comment 1 James Ralston 2016-07-21 13:32 EDT
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.
Comment 2 Tomas Mraz 2016-07-21 14:00:59 EDT
I agree, however to properly prioritize the issue could you please report it also through regular support channels?
http://www.redhat.com/support
Comment 3 Tomas Mraz 2016-07-21 14:37:29 EDT
*** Bug 1358880 has been marked as a duplicate of this bug. ***
Comment 4 James Ralston 2016-07-21 15:21:25 EDT
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.)
Comment 5 James Ralston 2016-07-21 15:23:21 EDT
Also, RHEL6 has the exact same bug, so it should be squashed there, too. Should I clone this bug for RHEL6?
Comment 6 Tomas Mraz 2016-07-22 02:47:55 EDT
Please, just report that via the support case.
Comment 19 errata-xmlrpc 2018-04-10 07:35:33 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:0718

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