Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1359303 - pam access.conf file misparses group names that contain "@" characters
Summary: pam access.conf file misparses group names that contain "@" characters
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: pam
Version: 6.9
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Tomas Mraz
QA Contact: Patrik Kis
URL:
Whiteboard:
Depends On: 1358881
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-22 18:06 UTC by kludhwan
Modified: 2017-03-21 11:34 UTC (History)
5 users (show)

Fixed In Version: pam-1.1.1-23.el6
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1358881
Environment:
Last Closed: 2017-03-21 11:34:21 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:0759 normal SHIPPED_LIVE pam bug fix and enhancement update 2017-03-21 12:46:49 UTC

Description kludhwan 2016-07-22 18:06:42 UTC
+++ This bug was initially created as a clone of Bug #1358881 +++

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.

--- Additional comment from James Ralston on 2016-07-21 13:32 EDT ---

I think the best way to address this is to check for a '(group)' construct first, before attempting to parse for '@' characters.

--- Additional comment from Tomas Mraz on 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

--- Additional comment from Tomas Mraz on 2016-07-21 14:37:29 EDT ---



--- Additional comment from James Ralston on 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.)

--- Additional comment from James Ralston on 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?

--- Additional comment from Tomas Mraz on 2016-07-22 02:47:55 EDT ---

Please, just report that via the support case.

Comment 7 errata-xmlrpc 2017-03-21 11:34:21 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, 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://rhn.redhat.com/errata/RHBA-2017-0759.html


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