Bug 206183 - Dropped capabilities show in the 'Current' set
Summary: Dropped capabilities show in the 'Current' set
Status: RESOLVED PATCH_ALREADY_AVAILABLE
Alias: None
Product: Tools
Classification: Unclassified
Component: libcap (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Tools/Libcap default virtual assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-13 10:24 UTC by Frantisek Sumsal
Modified: 2020-01-24 10:24 UTC (History)
2 users (show)

See Also:
Kernel Version: all
Tree: Mainline
Regression: No


Attachments

Description Frantisek Sumsal 2020-01-13 10:24:11 UTC
Hello!

After upgrading to the latest Arch Linux with libcap-2.29, our systemd testsuite[0] started suddenly failing. By delving a little bit deeper, it looks like since commit[1] `capsh` shows dropped named capabilities as part of the `Current` set:

Old libcap (2.28):

```
# capsh --drop=cap_mknod  -- -c 'capsh --print'
Current: = cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read+ep
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read
Ambient set =
Securebits: 00/0x0/1'b0
 secure-noroot: no (unlocked)
 secure-no-suid-fixup: no (unlocked)
 secure-keep-caps: no (unlocked)
 secure-no-ambient-raise: no (unlocked)
uid=0(root)
gid=0(root)
groups=0(root)

```

New libcap (2.29):
```
# capsh --drop=cap_mknod  -- -c 'capsh --print'
Current: =ep cap_mknod,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63-ep
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read
Ambient set =
Securebits: 00/0x0/1'b0
 secure-noroot: no (unlocked)
 secure-no-suid-fixup: no (unlocked)
 secure-keep-caps: no (unlocked)
 secure-no-ambient-raise: no (unlocked)
uid=0(root) euid=0(root)
gid=0(root)
groups=0(root)
Guessed mode: UNCERTAIN (0)
```

Is this expected, and I'm just missing something obvious, or it's a bug?

Thank you.

[0] https://github.com/systemd/systemd/issues/14548
[1] https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=afef3ef1c62613e1cac12a2bbec6017f7d5e033e
Comment 1 Andrew G. Morgan 2020-01-13 16:17:33 UTC
Can you do ldd capsh ? I'm wondering if you are linking dynamically and linking to the older libcap?

In a libcap build tree, which links capsh statically, your command yields this:

$ ldd progs/capsh
$ sudo progs/capsh --drop=cap_mknod  -- -c 'capsh --print'
Current: =eip
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read
Ambient set =
Securebits: 00/0x0/1'b0
 secure-noroot: no (unlocked)
 secure-no-suid-fixup: no (unlocked)
 secure-keep-caps: no (unlocked)
 secure-no-ambient-raise: no (unlocked)
uid=0(root) euid=0(root)
gid=0(root)
groups=0(root)
Guessed mode: UNCERTAIN (0)
Comment 2 Andrew G. Morgan 2020-01-13 16:18:03 UTC
That is:

$ ldd progs/capsh
        not a dynamic executable
Comment 3 Andrew G. Morgan 2020-01-13 16:20:20 UTC
[The 'i' in my inheritable set is some stupidity with the Linux distribution I'm running.. Please ignore that.]
Comment 4 Frantisek Sumsal 2020-01-13 16:52:29 UTC
[root@arch vagrant]# capsh --drop=cap_mknod  -- -c 'capsh --print'
Current: =ep cap_mknod,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63-ep
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read
Ambient set =
Securebits: 00/0x0/1'b0
 secure-noroot: no (unlocked)
 secure-no-suid-fixup: no (unlocked)
 secure-keep-caps: no (unlocked)
 secure-no-ambient-raise: no (unlocked)
uid=0(root) euid=0(root)
gid=0(root)
groups=0(root)
Guessed mode: UNCERTAIN (0)

[root@arch vagrant]# ldd `which capsh`
	linux-vdso.so.1 (0x00007fff26dbb000)
	libcap.so.2 => /usr/lib/libcap.so.2 (0x00007ff72bbc8000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007ff72ba00000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007ff72bbf0000)

[root@arch vagrant]# pacman -Q libcap
libcap 2.29-1

[root@arch vagrant]# pacman -Ql libcap | grep libcap.so
libcap /usr/lib/libcap.so
libcap /usr/lib/libcap.so.2
libcap /usr/lib/libcap.so.2.29

[root@arch vagrant]# ls -la /usr/lib/libcap.so*
lrwxrwxrwx 1 root root    11 Dec 25 23:34 /usr/lib/libcap.so -> libcap.so.2
lrwxrwxrwx 1 root root    14 Dec 25 23:34 /usr/lib/libcap.so.2 -> libcap.so.2.29
-rw-r--r-- 1 root root 26544 Dec 25 23:34 /usr/lib/libcap.so.2.29
Comment 5 Frantisek Sumsal 2020-01-13 17:07:07 UTC
Also, I tried to compile the latest libcap version and test with that (on a different system, F31) with following results:

$ ldd progs/capsh
	not a dynamic executable

$ sudo progs/capsh --drop=cap_mknod  -- -c '$PWD/progs/capsh --print'
Current: =ep cap_mknod-ep
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read
Ambient set =
Securebits: 00/0x0/1'b0
 secure-noroot: no (unlocked)
 secure-no-suid-fixup: no (unlocked)
 secure-keep-caps: no (unlocked)
 secure-no-ambient-raise: no (unlocked)
uid=0(root) euid=0(root)
gid=0(root)
groups=0(root)
Guessed mode: UNCERTAIN (0)
Comment 6 Andrew G. Morgan 2020-01-13 17:33:48 UTC
Yes, more coffee needed.

I guess I was testing with the latest tree. It would appear that something in 2.29 was still getting confused about what "all" meant. The decode of the bits still appears to assume all was the full 64-bits.

libcap-2.30 appears to not have that issue. Do you have a reason not to upgrade to 2.30?
Comment 7 Andrew G. Morgan 2020-01-13 17:39:20 UTC
I believe it is something in here that fixed it:

https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=f1f62a748d7c67361e91e32d26abafbfb03eeee4
Comment 8 Frantisek Sumsal 2020-01-13 17:51:56 UTC
Ah, thank you, now it makes sense. I got confused by seeing the dropped capability in the fixed version as well, but only just now I noticed the '-ep' suffix, which actually lowers the preceding capabilities.

In that case the issue seems to be indeed resolved by switching to v2.30. Thank you!

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