On Fri 2024-01-05 09:49:44, Theodore Ts'o wrote: > It's unclear to me what goal you have in trying to mess with the > capability definitions? Perhaps it might be useful if you were to > explicitly state your goals in these proposals?
Petr is right, we are trying to resolve the overlap problem of capability. Capability is about to separate superuser privileges into distinct units for finer-grained access control. It’s effective work requires the kernel to use proper capability for sensitive resources and the user programs to choose the right capability instead of ROOT to execute. And we want to promote the standardized use of capability. > So there isn't all that much upside in trying to retire CAP_SYS_ADMIN We are not going to retire CAP_SYS_ADMIN, but saying that CAP_SYSLOG is the more appropriate capability when it comes to protecting syslog functionality. CAP_SYS_ADMIN is already overloaded, check out the link[1], narrowing down its definitions will facilitate the implementation of least privilege. This adjustment makes it clearer for a user program requiring syslog access to specify only the necessary capability, CAP_SYSLOG, instead of relying on the broader CAP_SYS_ADMIN. > What testing have you done to make sure that this is OK? We booted the modified kernel and confirmed that CAP_SYS_ADMIN no longer has access to syslog when dmesg is set. While certain user programs relying on CAP_SYS_ADMIN for syslog access might be impacted, they can adjust their capability configuration using the ‘setcap’ command. Decreasing the reliance on CAP_SYS_ADMIN across applications contributes to minimizing security risks in the system. Currently, it's uncertain if any such programs exist. Best regrads, Jingzi [1]: https://lwn.net/Articles/486306/
