Back to bug 1950187
| Who | When | What | Removed | Added |
|---|---|---|---|---|
| Red Hat Bugzilla | 2021-04-16 01:55:48 UTC | Pool ID | sst_security_special_projects_rhel_8 | |
| Red Hat One Jira (issues.redhat.com) | 2021-04-16 01:56:16 UTC | Link ID | Red Hat Issue Tracker RHELPLAN-75171 | |
| Red Hat One Jira (issues.redhat.com) | 2021-04-16 01:56:21 UTC | Link ID | Red Hat Issue Tracker SECENGSP-3725 | |
| Marc Sauton | 2021-04-16 23:58:00 UTC | CC | msauton | |
| Marc Sauton | 2021-04-20 19:18:45 UTC | Priority | unspecified | high |
| Hardware | Unspecified | All | ||
| OS | Unspecified | Linux | ||
| Severity | medium | high | ||
| James Hartsock | 2021-04-27 12:42:13 UTC | CC | hartsjc, zfridric | |
| Flags | needinfo?(zfridric) | |||
| Zoltan Fridrich | 2021-04-28 12:24:09 UTC | Flags | needinfo?(zfridric) | |
| Martin Zelený | 2021-04-29 12:22:03 UTC | CC | mzeleny | |
| QA Contact | qe-baseos-security | mzeleny | ||
| Ondrej Moriš | 2021-04-29 13:13:14 UTC | CC | omoris | |
| Zoltan Fridrich | 2021-05-05 07:29:11 UTC | Keywords | Triaged | |
| James Hartsock | 2021-05-12 11:56:04 UTC | Flags | needinfo?(zfridric) | |
| Zoltan Fridrich | 2021-05-13 09:14:15 UTC | Flags | needinfo?(zfridric) | |
| Lukas Vrabec | 2021-05-17 17:03:11 UTC | CC | lvrabec | |
| Flags | needinfo?(hartsjc) | |||
| James Hartsock | 2021-05-21 11:46:49 UTC | Flags | needinfo?(hartsjc) | |
| Andrew G. Morgan | 2021-05-25 14:13:14 UTC | CC | morgan | |
| James Hartsock | 2021-06-10 13:03:35 UTC | Link ID | Red Hat Knowledge Base (Solution) 1264083 | |
| Zoltan Fridrich | 2021-06-25 07:58:20 UTC | Status | NEW | ASSIGNED |
| Jan Pazdziora | 2021-09-17 18:14:03 UTC | CC | jpazdziora | |
| James Hartsock | 2021-12-09 01:17:44 UTC | Flags | needinfo?(zfridric) | |
| Zoltan Fridrich | 2021-12-09 11:30:36 UTC | Flags | needinfo?(zfridric) | |
| Zoltan Fridrich | 2021-12-15 12:36:50 UTC | Status | ASSIGNED | POST |
| Zoltan Fridrich | 2021-12-22 12:25:07 UTC | Doc Type | If docs needed, set a value | Bug Fix |
| Depends On | 2033566 | |||
| Doc Text | Cause: After changing uid from root to non-root, permitted, effective and ambient sets of capabilities are nullified. This is the correct behavior (safety measure) according to capabilities manual page. Consequence: pam_cap.so module is unable to set ambient capabilities because in order for a capability to be in the ambient set, it needs to be in both permitted and inheritable set. But the permitted set gets nullified after setuid, therefore the ambient capability can not be set. Fix: It does not seem to be possible to fix this solely in libcap. There is a lot of moving parts that has to correctly work together like PAM, su, login, ... . To fix the issue, pam_cap.so module now supports keepcaps option which sets SECBIT_KEEP_CAPS flag to allow calling proccess to retain it's permitted capabilities after setuid from root to non-root (but the flag gets reset after execve). pam_cap.so module now also supports defer option, this causes pam_cap.so to reapply ambient capabilities within a callback to pam_end() which should be called from other applications after changing uid. Result: If su and login commands are updated and PAM compliant. Use pam_cap.so with keepcaps and defer options to be able to set ambient capabilities for non-root users. | |||
| Priority | high | medium | ||
| Welterlen Benoit | 2021-12-22 16:37:26 UTC | CC | bwelterl | |
| Zoltan Fridrich | 2022-01-05 09:16:12 UTC | Depends On | 2037212 | |
| Zoltan Fridrich | 2022-01-05 09:19:38 UTC | Blocks | 2037215 | |
| Zoltan Fridrich | 2022-01-05 09:23:00 UTC | Blocks | 2037215 | |
| Zoltan Fridrich | 2022-01-05 09:24:08 UTC | Depends On | 2037212 | |
| Zoltan Fridrich | 2022-01-28 11:33:39 UTC | Fixed In Version | util-linux-2.32.1-31.el8 | |
| Fixed In Version | util-linux-2.32.1-31.el8 | libcap-2.48-1.el8 | ||
| Zoltan Fridrich | 2022-01-28 11:36:55 UTC | Status | POST | MODIFIED |
| Jan Fiala | 2022-01-31 10:59:23 UTC | CC | jafiala | |
| Docs Contact | jafiala | |||
| errata-xmlrpc | 2022-01-31 11:32:06 UTC | Status | MODIFIED | ON_QA |
| Jan Fiala | 2022-01-31 14:33:30 UTC | Doc Text | Cause: After changing uid from root to non-root, permitted, effective and ambient sets of capabilities are nullified. This is the correct behavior (safety measure) according to capabilities manual page. Consequence: pam_cap.so module is unable to set ambient capabilities because in order for a capability to be in the ambient set, it needs to be in both permitted and inheritable set. But the permitted set gets nullified after setuid, therefore the ambient capability can not be set. Fix: It does not seem to be possible to fix this solely in libcap. There is a lot of moving parts that has to correctly work together like PAM, su, login, ... . To fix the issue, pam_cap.so module now supports keepcaps option which sets SECBIT_KEEP_CAPS flag to allow calling proccess to retain it's permitted capabilities after setuid from root to non-root (but the flag gets reset after execve). pam_cap.so module now also supports defer option, this causes pam_cap.so to reapply ambient capabilities within a callback to pam_end() which should be called from other applications after changing uid. Result: If su and login commands are updated and PAM compliant. Use pam_cap.so with keepcaps and defer options to be able to set ambient capabilities for non-root users. | .Ambient capabilities no longer fail to be applied to non-root users Changing UID (User Identifier) from root to non-root nullifies permitted, effective and ambient sets of capabilities. This is the correct behavior according to capabilities manual page and acts as a safety measure. However, the `pam_cap.so` module is unable to set ambient capabilities because in order for a capability to be in the ambient set, it needs to be in both the permitted and the inheritable set. But because the permitted set gets nullified after changing the UID (for example by using the `setuid` utility), the ambient capability cannot be set. To fix the issue, the `pam_cap.so` module now supports the `keepcaps` option which sets the `SECBIT_KEEP_CAPS` flag to allow calling a process to retain its permitted capabilities after changing the UID from root to non-root. However, the flag resets after using the `execve` utility). The `pam_cap.so` module now also supports the `defer` option, which causes `pam_cap.so` to reapply ambient capabilities within a callback to `pam_end()`, which should be called from other applications after changing the UID. If the `su` and `login` utilities are updated and PAM-compliant, you can use `pam_cap.so` with the `keepcaps` and `defer` options to be able to set ambient capabilities for non-root users. |
| Flags | needinfo?(zfridric) | |||
| Jan Fiala | 2022-01-31 14:38:48 UTC | Flags | needinfo?(zfridric) | |
| Jan Fiala | 2022-01-31 15:41:12 UTC | Doc Text | .Ambient capabilities no longer fail to be applied to non-root users Changing UID (User Identifier) from root to non-root nullifies permitted, effective and ambient sets of capabilities. This is the correct behavior according to capabilities manual page and acts as a safety measure. However, the `pam_cap.so` module is unable to set ambient capabilities because in order for a capability to be in the ambient set, it needs to be in both the permitted and the inheritable set. But because the permitted set gets nullified after changing the UID (for example by using the `setuid` utility), the ambient capability cannot be set. To fix the issue, the `pam_cap.so` module now supports the `keepcaps` option which sets the `SECBIT_KEEP_CAPS` flag to allow calling a process to retain its permitted capabilities after changing the UID from root to non-root. However, the flag resets after using the `execve` utility). The `pam_cap.so` module now also supports the `defer` option, which causes `pam_cap.so` to reapply ambient capabilities within a callback to `pam_end()`, which should be called from other applications after changing the UID. If the `su` and `login` utilities are updated and PAM-compliant, you can use `pam_cap.so` with the `keepcaps` and `defer` options to be able to set ambient capabilities for non-root users. | .Ambient capabilities are now applied correctly to non-root users As a safety measure, changing a UID (User Identifier) from root to non-root nullifies permitted, effective, and ambient sets of capabilities. However, the `pam_cap.so` module is unable to set ambient capabilities because a capability needs to be in both the permitted and the inheritable set to be in the ambient set. In addition, the permitted set gets nullified after changing the UID (for example by using the `setuid` utility), so the ambient capability cannot be set. To fix this problem, the `pam_cap.so` module now supports the `keepcaps` option, which allows a process to retain its permitted capabilities after changing the UID from root to non-root. The `pam_cap.so` module now also supports the `defer` option, which causes `pam_cap.so` to reapply ambient capabilities within a callback to `pam_end()`. This callback can be used by other applications after changing the UID. Therefore, if the `su` and `login` utilities are updated and PAM-compliant, you can now use `pam_cap.so` with the `keepcaps` and `defer` options to set ambient capabilities for non-root users. |
| Zoltan Fridrich | 2022-01-31 16:07:21 UTC | Flags | needinfo?(zfridric) needinfo?(zfridric) | |
| errata-xmlrpc | 2022-02-01 09:14:20 UTC | Status | ON_QA | VERIFIED |
| errata-xmlrpc | 2022-05-10 01:02:28 UTC | Status | VERIFIED | RELEASE_PENDING |
| errata-xmlrpc | 2022-05-10 15:31:04 UTC | Resolution | --- | ERRATA |
| Status | RELEASE_PENDING | CLOSED | ||
| Last Closed | 2022-05-10 15:31:04 UTC | |||
| errata-xmlrpc | 2022-05-10 15:31:08 UTC | Link ID | Red Hat Product Errata RHBA-2022:2103 | |
| Flos Qi Guo | 2023-01-19 09:18:40 UTC | CC | qguo |
Back to bug 1950187