Bug 1035427

Summary: capng_lock sets securebits in a scary manner
Product: [Fedora] Fedora Reporter: Andy Lutomirski <luto>
Component: libcap-ngAssignee: Steve Grubb <sgrubb>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 22CC: pcfe, sgrubb
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-07-19 10:38:44 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: 885288, 1093702, 1095222    
Attachments:
Description Flags
Possible fix none

Description Andy Lutomirski 2013-11-27 18:15:31 UTC 
Created attachment 829864 [details]
Possible fix

capng_lock sets securebits in an attempt to prevent regaining capabilities using setuid-root programs.  This works, but it has little effect on setcap'd programs, and it allows a user to run setuid programs as uid 0 but without capabilities, which is potentially dangerous.  (It could, for example, be used to trigger the sendmail bug.)

To be clear, I don't know of anything in Fedora that's exploitable.  Code that did:

capng_lock()
execve untrusted program
execve setuid program that does:
setuid(getuid())
dlopen (or other code path that runs untrusted code w/o execve first)

would be exploitable because the saved uid would be zero.

This can be tested on Fedora like this:

$ seunshare -t tmp -- /bin/setpriv -d
uid: 500
euid: 500
gid: 500
egid: 500
Supplementary groups: 10,18,39,468,469,480,500
no_new_privs: 0
Inheritable capabilities: [none]
Capability bounding set: chown,dac_override,dac_read_search,fowner,fsetid,kill,setgid,setuid,setpcap,linux_immutable,net_bind_service,net_broadcast,net_admin,net_raw,ipc_lock,ipc_owner,sys_module,sys_rawio,sys_chroot,sys_ptrace,sys_psacct,sys_admin,sys_boot,sys_nice,sys_resource,sys_time,sys_tty_config,mknod,lease,audit_write,audit_control,setfcap,mac_override,mac_admin,syslog,wake_alarm,block_suspend,compromise_kernel
Securebits: noroot,noroot_locked,no_setuid_fixup,no_setuid_fixup_locked
SELinux label: unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

With the attached patch, the result is less worrisome:

$ seunshare -t tmp -- /bin/setpriv -d
uid: 500
euid: 500
gid: 500
egid: 500
Supplementary groups: 10,18,39,468,469,480,500
no_new_privs: 1
Inheritable capabilities: [none]
Capability bounding set: chown,dac_override,dac_read_search,fowner,fsetid,kill,setgid,setuid,setpcap,linux_immutable,net_bind_service,net_broadcast,net_admin,net_raw,ipc_lock,ipc_owner,sys_module,sys_rawio,sys_chroot,sys_ptrace,sys_psacct,sys_admin,sys_boot,sys_nice,sys_resource,sys_time,sys_tty_config,mknod,lease,audit_write,audit_control,setfcap,mac_override,mac_admin,syslog,wake_alarm,block_suspend,cap_37
Securebits: [none]
SELinux label: unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

This change would have mitigated this exploit:

http://permalink.gmane.org/gmane.comp.security.full-disclosure/78265

See also https://bugzilla.redhat.com/show_bug.cgi?id=885288
Comment 1 Steve Grubb 2014-04-30 13:54:09 UTC 
Not 100% sure this is the correct fix. Still looking at the kernel. In the meantime, the patch hides the problem. Libcap-ng-0.7.4 was pushed live in F20.
Comment 2 Andy Lutomirski 2014-04-30 15:31:33 UTC 
Looks okay to me.

The whole point of no_new_privs is that it's supposed to safe to do things that could break setuid programs as long as no_new_privs is set.  For example, installing a malicious seccomp filter could probably subvert almost any setuid binary, so you can only install seccomp filters if you are root or if you set no_new_privs first.
Comment 3 Steve Grubb 2014-04-30 15:39:01 UTC 
The issue to me is that I think SECURE_NOROOT doesn't get its semantics right as is. I'm thinking if noroot is set and cap_setuid is set, suid as normal but with no capabilities. If no_root is set and cap_setuid is unset, no transition should occur. If no_root is unset, then works as normal.

If this was not the intention, then SECURE_NOSUID should have been created at the same time the other SECUREBITS options were created so that each part of credential escalation could be controlled.
Comment 4 Andy Lutomirski 2014-04-30 15:57:59 UTC 
TBH, the whole Linux capability inheritance system (i.e. what happens on exec) is terminally screwed up.  That being said, lacking cap_setuid shouldn't prevent the setuid bit from working -- most users lack cap_setuid.

If I were maintaining cap-ng, I'd just ditch the securebits stuff -- I don't think that the kernel implementation was ever thought through very well.
Comment 5 Steve Grubb 2014-05-01 02:41:11 UTC 
libcap-ng-0.7.4-2 was put in rawhide reverting this change because it caused bug 1091761. I also unpushed libcap-ng-0.7.4 from F19. Pending testing on rawhide, I will push a new package reverting PR_SET_NO_NEW_PRIVS in F20.

I really think fixing the semantics of NOROOT as described above is the real and ultimate fix.
Comment 6 Patrick C. F. Ernzer 2014-05-04 09:40:19 UTC 
FWIW, libcap-ng-0.7.4-2.fc21 solves bug 1093702 (sandboxed X apps no longer working [F20]) for me. Thanks!

Is there anything besides
 $ sandbox -t sandbox_web_t -X firefox http://www.redhat.com/
 $ sandbox -X okular Project_TeddyBears_Siggraph14_paper.pdf
you'd like me to test? (While this is a KDE install, I can install evice or any other application on the box for testing if needed)
Comment 7 Jaroslav Reznik 2015-03-03 15:14:27 UTC 
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Comment 8 Steve Grubb 2015-05-13 12:31:44 UTC 
I am wondering if this bz can be closed? libcap-ng 0.7.5 is in F21/22 now.
Comment 9 Fedora End Of Life 2016-07-19 10:38:44 UTC 
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.