Re: [PATCH] cap_syslog: remove CAP_SYS_ADMIN when dmesg_restrict

[孟敬姿]

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/