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 919385 - Cannot use newrole with unprivileged user
Summary: Cannot use newrole with unprivileged user
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: policycoreutils
Version: 7.0
Hardware: All
OS: All
urgent
urgent
Target Milestone: beta
: ---
Assignee: Daniel Walsh
QA Contact: Miroslav Vadkerti
URL:
Whiteboard:
Depends On:
Blocks: RHEL7CCC
TreeView+ depends on / blocked
 
Reported: 2013-03-08 10:40 UTC by Miroslav Vadkerti
Modified: 2014-06-18 02:39 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-13 09:43:36 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Strace of newrole -r (313.67 KB, text/plain)
2013-03-08 10:40 UTC, Miroslav Vadkerti 		no flags Details
patch to fix problem. stop messing with bset (1.35 KB, patch)
2013-03-12 19:11 UTC, Eric Paris 		no flags Details | Diff
really fix it this time! (4.82 KB, patch)
2013-03-14 20:13 UTC, Eric Paris 		no flags Details | Diff
Show Obsolete (1) View All

Description Miroslav Vadkerti 2013-03-08 10:40:23 UTC 
Created attachment 706980 [details]
Strace of newrole -r

Description of problem:
I cannot change role as a unprivileged staff_u user using newrole:

[eal/staff_r/s0@dhcp-25-168 ~]$ newrole -r sysadm_r
Password: (enter correct password)
newrole: incorrect password for eal

In /var/log/secure I see these weird messages:
Mar  8 05:27:34 dhcp-25-168 unix_chkpwd[7022]: check pass; user unknown
Mar  8 05:27:37 dhcp-25-168 unix_chkpwd[7023]: check pass; user unknown
Mar  8 05:27:37 dhcp-25-168 unix_chkpwd[7023]: password check failed for user (eal)
Mar  8 05:27:37 dhcp-25-168 newrole: pam_unix(newrole:auth): authentication failure; logname=eal uid=1000 euid=1000 tty=pts/5 ruser= rhost=  user=eal

I was able to get strace from the newrole calling (see attachement)

Capabilities and permissions on unix_chkpwd and newrole
# getcap $(which unix_chkpwd) $(which newrole); ll -Z $(which unix_chkpwd) $(which newrole)
/bin/newrole = cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_setpcap,cap_sys_admin,cap_audit_write+ep
-rwxr-xr-x. root root system_u:object_r:newrole_exec_t:s0 /bin/newrole
-rwsr-xr-x. root root system_u:object_r:chkpwd_exec_t:s0 /sbin/unix_chkpwd

Version-Release number of selected component (if applicable):
policycoreutils-python-2.1.14-8.el7.x86_64
pam-1.1.6-3.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1. useardd eal
2. assign staff_u to eal
3. login as eal and try to newrole to sysadm_r
  
Actual results:
Cannot use newrole

Expected results:
Newrole can be used to switch to permitted roles

Additional info:
I discussed this issue with tmraz via IRC. According to his comments newrole drops capabilities (see below) and even unix_chkpwd is setuid the capabilities seem not be restored

If we drop capabilities from newrole we can see it tries to drop them:
# setcap -r $(which newrole)
$ newrole -r sysadm_r
Sorry, newrole failed to drop capabilities
: Operation not permitted
Comment 2 Tomas Mraz 2013-03-08 10:44:38 UTC 
It doesn't make much sense to me to have the newrole such huge set of powerful setcaps. They are root equivalent anyway so making it a simple setuid binary would be much cleaner. And if the capabilities are dropped they have to be dropped only after the PAM calls, not before.
Comment 4 Daniel Walsh 2013-03-08 19:40:01 UTC 
Update to the latest policycoreutils this has already been reported and fixed.

policycoreutils-2.1.14-20.el7 is the current build for RHEL7.
Comment 7 Daniel Walsh 2013-03-11 20:03:29 UTC 
I can not seem to get this to work.  Seems if I drop privs unix_chkpwd blows up with wrong password(Event though the password is correct).  If I don't drop privs before calling pam_authenticate, I seem to loose privs anyways and when I try to drop_privs after authentication.  It fails.
Comment 8 Daniel Walsh 2013-03-11 20:04:13 UTC 
If I don't drop capabilities at all, everything works and the resulting shell has no capabilities.
Comment 9 Daniel Walsh 2013-03-11 20:08:20 UTC 
# ls -l /usr/bin/newrole
-rwsr-xr-x. 1 root root 38612 Mar 11 15:59 /usr/bin/newrole

As a normal user
> newrole -r sysadm_r
Password:

Back as root.

# ps -eZ | grep newrole
staff_u:staff_r:newrole_t:s0-s0:c0.c1023 8508 pts/5 00:00:00 newrole
# getpcaps 8508
Capabilities for `8508': =ep

> Complete newrole

The audit message does get written.

# newrole -r sysadm_r
Password: 

 Dup dor a'az Mubster!              \_____/    Bonjour, enfants du monde!
 Ciao, bambini di tutto il mondo!   || o ||    ¡Hola, chicos del mundo!
 Hallo, Kinder der Welt!            |._X_.|    Hallo, kinderen van de wereld!
 Hello, children of the world!     //_=_=_\\   Olá, crianças do mundo!

bash-4.2$ getpcaps $$
Capabilities for `8740': =

Is there a problem calling one setuid program "unix_chkpwd" from another setuid program newrole?
Comment 10 Eric Paris 2013-03-12 17:51:17 UTC 
Given that I see cap_setpcap in the fcaps, I'm assuming newrole is dropping things from the bset?  If that's the case, no future suid app can ever regain those apps.  Seems to me like newrole needs to stop dropping things from the bset and give up setpcap....
Comment 11 Eric Paris 2013-03-12 19:11:23 UTC 
Created attachment 709119 [details]
patch to fix problem.  stop messing with bset
Comment 14 Eric Paris 2013-03-14 20:13:05 UTC 
Created attachment 710206 [details]
really fix it this time!
Comment 15 Miroslav Vadkerti 2013-03-15 10:43:12 UTC 
Thanks very much for the fix! I cannot reproduce the issue anymore with policycoreutils-2.1.14-22.el7

$ newrole -r lspp_test_r
Password: 
$ /bin/su -
Password: 
# rpm -q policycoreutils
policycoreutils-2.1.14-22.el7.x86_64
# getenforce 
Enforcing

The ASSIGNED state seems bogus here. Moving to VERIFIED. This will be tested during CC, no need for a other tests.
Comment 16 Ludek Smid 2014-06-13 09:43:36 UTC 
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.
Note You need to log in before you can comment on or make changes to this bug.