Bug 919385
Summary: | Cannot use newrole with unprivileged user | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Miroslav Vadkerti <mvadkert> | ||||||||
Component: | policycoreutils | Assignee: | Daniel Walsh <dwalsh> | ||||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Miroslav Vadkerti <mvadkert> | ||||||||
Severity: | urgent | Docs Contact: | |||||||||
Priority: | urgent | ||||||||||
Version: | 7.0 | CC: | arubin, dwalsh, eparis, mgrepl, mmalik, sforsber, sgrubb, tmraz | ||||||||
Target Milestone: | beta | Keywords: | 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: |
|
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. Update to the latest policycoreutils this has already been reported and fixed. policycoreutils-2.1.14-20.el7 is the current build for RHEL7. 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. If I don't drop capabilities at all, everything works and the resulting shell has no capabilities. # 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? 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.... Created attachment 709119 [details]
patch to fix problem. stop messing with bset
Created attachment 710206 [details]
really fix it this time!
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. 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. |
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