Bug 919385

Summary: Cannot use newrole with unprivileged user
Product: Red Hat Enterprise Linux 7 Reporter: Miroslav Vadkerti <mvadkert>
Component: policycoreutilsAssignee: Daniel Walsh <dwalsh>
Status: CLOSED CURRENTRELEASE QA Contact: Miroslav Vadkerti <mvadkert>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 7.0CC: arubin, dwalsh, eparis, mgrepl, mmalik, sforsber, sgrubb, tmraz
Target Milestone: betaKeywords: Regression, TestBlocker
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-13 09:43:36 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: 717785    
Attachments:
Description Flags
Strace of newrole -r
none
patch to fix problem. stop messing with bset
none
really fix it this time! none

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.