Bug 1035427 - capng_lock sets securebits in a scary manner
Summary: capng_lock sets securebits in a scary manner
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: libcap-ng
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Steve Grubb
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 885288 1093702 1095222
TreeView+ depends on / blocked
 
Reported: 2013-11-27 18:15 UTC by Andy Lutomirski
Modified: 2016-07-19 10:38 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-07-19 10:38:44 UTC
Type: Bug


Attachments (Terms of Use)
Possible fix (3.23 KB, patch)
2013-11-27 18:15 UTC, Andy Lutomirski
no flags Details | Diff

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.


Note You need to log in before you can comment on or make changes to this bug.