CAP_PERFMON — and new capabilities in general

Posted Feb 23, 2020 7:08 UTC (Sun) by matthias (subscriber, #94967)
Parent article: CAP_PERFMON — and new capabilities in general

> One reason, of course, is the aforementioned compatibility issue: once CAP_SYS_ADMIN allows an action, it can never lose that power without possibly breaking existing systems. When Serge Hallyn added CAP_SYSLOG, he added the usual code that made things continue to work if the process in question had CAP_SYS_ADMIN. In that case, though, the kernel issues a warning that use of CAP_SYS_ADMIN for these operations is deprecated. Nearly ten years later, the compatibility code — and the warning — remain. Splitting capabilities out of CAP_SYS_ADMIN is less than fully rewarding when the power of CAP_SYS_ADMIN itself can never be reduced.

I do not buy this. The compatibility code could be made optional in kernel config. There already are a bunch of options that say in the help text "Only enable this if you want to run binaries from the stone age." Probably there is no demand for such an option because CAP_SYS_ADMIN is omnipotent anyway. The reward for splitting capabilities out of CAP_SYS_ADMIN is not that CAP_SYS_ADMIN becomes less powerfull. The reward is that less processes need the power of CAP_SYS_ADMIN and processes can use less privileged capabilities instead.