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
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.
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.
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.
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.
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.
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)
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
I am wondering if this bz can be closed? libcap-ng 0.7.5 is in F21/22 now.
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.