Hide Forgot
Description of problem: Ambient capability is supported by libcap-2.26-4.el8 (Bug 1487388) And works for root. However, it does not work for non-root users. Output of capsh --print: ~~~ $ capsh --print Current: = cap_setpcap+i 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_mknod,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,38,39 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) ... ~~~ Version-Release number of selected component (if applicable): libcap-2.26-4.el8 How reproducible: Always for non-root user Steps to Reproduce: 1. Edit /etc/security/capability.conf ~~~ ^cap_setpcap testuser none * ~~~ 2. Edit /etc/pam.d/system-auth like ~~~ auth required pam_env.so auth required pam_faildelay.so delay=2000000 auth optional pam_cap.so debug ... ~~~ 3.Run following ~~~ su - testuser -c 'capsh --print' ~~~ Actual results: ~~~ Current: = cap_setpcap+i 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_mknod,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,38,39 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) ... ~~~ Expected results: Ambient set =cap_setpcap Additional info: Replacing "testuser" with "root" in capability.conf, the output of su - root -c 'capsh --print' was: ~~~ Current: = cap_setpcap+eip cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,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_mknod,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,38,39+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_mknod,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,38,39 Ambient set =cap_setpcap 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) ~~~
If I ssh, I see in the audit.log ( example capability.conf with cap_dac_read_search,^cap_net_raw,^cap_sys_nice test1 ) type=CAPSET msg=audit(1618616936.201:471): pid=23000 cap_pi=0000003fffffffff cap_pp=0000003fffffffff cap_pe=0000003fffffffff cap_pa=0000000000802000 ok for this: capsh --decode=0x0000000000802000 0x0000000000802000=cap_net_raw,cap_sys_nice ok for this too: getpcaps $$ Capabilities for `23250': = cap_dac_read_search,cap_net_raw,cap_sys_nice+i but not with this: egrep ^Cap /proc/$$/status CapInh: 0000000000802004 CapPrm: 0000000000000000 CapEff: 0000000000000000 CapBnd: 0000003fffffffff CapAmb: 0000000000000000 awk '/^Cap[ABEIP]/ {printf("%s ",$1); system("capsh --decode="$2)}' /proc/$$/status | sort CapAmb: 0x0000000000000000= CapBnd: 0x0000003fffffffff=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_mknod,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 CapEff: 0x0000000000000000= CapInh: 0x0000000000802004=cap_dac_read_search,cap_net_raw,cap_sys_nice CapPrm: 0x0000000000000000= not sure why the CapAmb is 0
(In reply to Marc Sauton from comment #1) ... > but not with this: > egrep ^Cap /proc/$$/status > CapInh: 0000000000802004 > CapPrm: 0000000000000000 > CapEff: 0000000000000000 > CapBnd: 0000003fffffffff > CapAmb: 0000000000000000 > ... > not sure why the CapAmb is 0 I am actually wondering if the problem you see isn't caused by empty CapPrm. Documentation for ambient capabilities [1] states that "pA obeys the invariant that no bit can ever be set in pA if it is not set in both pP and pI. Dropping a bit from pP or pI drops that bit from pA." Hence I assume that empty set of ambient capabilities in this case might actually be caused by having empty set of permitted capabilities. But I am still trying to understand why CapPrm is empty. It might be a bug. To answer question by James in c#5. We discussed this briefly and the answer is that there was no specific setup used to verify adding support for ambient capabilities to configuration file in RHEL-8.3 (BZ#1487388). At least I do not see anything like that in test script used to verify the bug (bz#1487388#c22), test was focused more on newly introduced syntax and verified capabilities using 'getpcaps' command that reveals only inheribable capabilities. Right it seems that we introduced incomplete fix 8.3 and it slipped through the QE process but I am not yet sure about that and it need a bit more investigation. [1] https://lwn.net/Articles/636533/
From what I found out, this is not really a bug as it is working according to manual pages, however it is a questionable behaviour. The capability is not present within the ambient set for non-root user, because the permitted set is empty. In order for capability to be ambient, it has to be also inheritable and permitted. From capabilities man page (Effect of user ID changes on capabilities): "If one or more of the real, effective or saved set user IDs was previously 0, and as a result of the UID changes all of these IDs have a nonzero value, then all capabilities are cleared from the permitted, effective, and ambient capability sets." This is why the permitted set is cleared (security measure). This behaviour can be bypassed (not recommended) by setting SECBIT_KEEP_CAPS flag (even though I was not able to make it work). It seems that there needs to be an option to set permitted capabilities for non-root users, otherwise the pam_cap ambient feature is unusable for them. I am currently discussing this with libcap upstream.
Think it is a bug based on how we have publically stated what libcap allows in RHEL 8.3 Release Notes (and what was requested in RFE for that matter). >libcap now supports ambient capabilities > >With this update, users are able to grant ambient capabilities at login and prevent the need to have root access for the appropriately configured processes. > >(BZ#1487388)
SECBIT_KEEP_CAPS actually works when used via capsh binary (ie. sudo --user <non-root-user> --keep 1 ....). Option 'keep=1' enables SECBIT_KEEP_CAPS. Zoltan, when using ambient capabilities from the configuration file - isn't it possible that pam_cap does not set the flag? As you pointed out using ambient capabilities for non-root users without SECBIT_KEEP_CAPS do not really make sense and hence pam_cap should perhaps do what capsh --keep 1 does. ~ $ sudo /usr/sbin/capsh --keep=1 --user=omoris --inh=cap_net_raw --addamb=cap_net_raw --print Current: = cap_net_raw+ip 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_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_mknod,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,38,39,40+p 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_mknod,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,38,39,40 Ambient set =cap_net_raw Securebits: 020/0x10/5'b10000 secure-noroot: no (unlocked) secure-no-suid-fixup: no (unlocked) secure-keep-caps: yes (unlocked) secure-no-ambient-raise: no (unlocked) uid=1000(omoris) gid=1000(omoris) groups=10(wheel),1000(omoris)
The problem with SECBIT_KEEP_CAPS is that user would have permitted set the same as root user (at least thats what I understood from the man page). The correct way would be just to add the requested ambient capability to permitted set.
(In reply to Zoltan Fridrich from comment #8) > > It seems that there needs to be an option to set permitted capabilities for > non-root users, otherwise the pam_cap ambient feature is unusable for them. > I am currently discussing this with libcap upstream. Is this discussion private, or is there a issue tracker or mailing group I could follow to keep up with progress?
This issue is discussed here: https://bugzilla.kernel.org/show_bug.cgi?id=212945 So far as I can tell the issue is related to the order of setuid and raising ambient bits (comment 3 of that bug).
The libcap 2.58 release will have a pam_cap.so able to set ambient vectors. The details are captured here: https://bugzilla.kernel.org/show_bug.cgi?id=214377#c3 Note, PAM apps may need bug fixes if they are not behaving as described in the pam_end(3) man page. The fedora su on my 34 based system appears to be such an app.
Thank you for letting me know. I did check the upstream work and the login and su PR. It looks good, I will test it on rhel-8.6 soon.
(In reply to Zoltan Fridrich from comment #21) > Thank you for letting me know. > I did check the upstream work and the login and su PR. It looks good, I will > test it on rhel-8.6 soon. How is testing on RHEL 8.6 going? I do not see ITR set yet.
Hello, after some time of testing and a lot of confusion I was able to verify (with the help of Andrew) that the upstream patch works and it does indeed fix this issue. However, there are several reasons why I did not set the ITR yet. 1. I was able to verify the solution just recently 2. I tested the solution on f35 as it can not be used as is on RHEL-8.6 due to incompatible versions of dependencies 3. RHEL-8.6 util-linux package also needs to be updated for this solution to work Current status: I am focused on rebasing the upstream solution onto RHEL-8.6 libcap. I should be able to set ITM and ITR in the near future (within 1 week hopefully)
Thank you for the information. I tried compiling the libcap-2.58 on Fedora 35 and was failing, so if you have any details to share on that would appreciate it.
FWIW the fedora RPM builds have been failing against more recent libcap releases, for a while. In the end I created my own .spec file and have been uploading it to the tracking bug: https://bugzilla.redhat.com/show_bug.cgi?id=1919609
I carried forward the libcap-use-compiler-flag-options.patch with tweaks to match changes, and was able to compile 2.58 and get RPM. But will give your builds a try, thank you.
I think that patch is likely to fail at some point in the future. As it is, the command line for make [all] already supplies those overrides. FWIW I've just uploaded a 2.62 spec file.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (libcap bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2022:2103