On 12/11/2019 2:52 AM, Alexey Budankov wrote: > On 05.12.2019 20:33, Casey Schaufler wrote: >> On 12/5/2019 9:05 AM, Alexey Budankov wrote: >>> Hello Casey, >>> >>> On 05.12.2019 19:49, Casey Schaufler wrote: >>>> On 12/5/2019 8:15 AM, Alexey Budankov wrote: >>>>> Currently access to perf_events functionality [1] beyond the scope permitted >>>>> by perf_event_paranoid [1] kernel setting is allowed to a privileged process >>>>> [2] with CAP_SYS_ADMIN capability enabled in the process effective set [3]. >>>>> >>>>> This patch set introduces CAP_SYS_PERFMON capability devoted to secure performance >>>>> monitoring activity so that CAP_SYS_PERFMON would assist CAP_SYS_ADMIN in its >>>>> governing role for perf_events based performance monitoring of a system. >>>>> >>>>> CAP_SYS_PERFMON aims to harden system security and integrity when monitoring >>>>> performance using perf_events subsystem by processes and Perf privileged users >>>>> [2], thus decreasing attack surface that is available to CAP_SYS_ADMIN >>>>> privileged processes [3]. >>>> Are there use cases where you would need CAP_SYS_PERFMON where you >>>> would not also need CAP_SYS_ADMIN? If you separate a new capability >>> Actually, there are. Perf tool that has record, stat and top modes could run with >>> CAP_SYS_PERFMON capability as mentioned below and provide system wide performance >>> data. Currently for that to work the tool needs to be granted with CAP_SYS_ADMIN. >> The question isn't whether the tool could use the capability, it's whether >> the tool would also need CAP_SYS_ADMIN to be useful. Are there existing >> tools that could stop using CAP_SYS_ADMIN in favor of CAP_SYS_PERFMON? >> My bet is that any tool that does performance monitoring is going to need >> CAP_SYS_ADMIN for other reasons. >> >>>> from CAP_SYS_ADMIN but always have to use CAP_SYS_ADMIN in conjunction >>>> with the new capability it is all rather pointless. >>>> >>>> The scope you've defined for this CAP_SYS_PERFMON is very small. >>>> Is there a larger set of privilege checks that might be applicable >>>> for it? >>> CAP_SYS_PERFMON could be applied broadly, though, this patch set enables record >>> and stat mode use cases for system wide performance monitoring in kernel and >>> user modes. >> The granularity of capabilities is something we have to watch >> very carefully. Sure, CAP_SYS_ADMIN covers a lot of things, but >> if we broke it up "properly" we'd have hundreds of capabilities. > Fully agree and this broader discussion is really helpful to come up with > properly balanced solution. > >> If you want control that finely we have SELinux. > Undoubtedly, SELinux is the powerful, mature, whole level of functionality that > could provide benefits not only for perf_events subsystem. However perf_events > is built around capabilities to provide access control to its functionality, > thus perf_events would require considerable rework prior it could be controlled > thru SELinux. Then the adoption could also require changes to the installed > infrastructure just for the sake of adopting alternative access control mechanism. > > On the other hand there are currently already existing users and use cases that > are built around the CAP_SYS_ADMIN based access control, and Perf tool, which is > the native Linux kernel observability and performance profiling tool, provides > means to operate in restricted multiuser environments(HPC clusters, cloud and > virtual environments) for groups of unprivileged users under admins control [1]. > > In this circumstances CAP_SYS_PERFMON looks like smart balanced advancement that > trade-offs between perf_events subsystem extensions, required level of control > and configurability of perf_events, existing users adoption effort, and it brings > security hardening benefits of decreasing attack surface for the existing users > and use cases. I'm not 100% opposed to CAP_SYS_PERFMON. I am 100% opposed to new capabilities that have a single use. Surely there are other CAP_SYS_ADMIN users that [cs]ould be converted to CAP_SYS_PERFMON as well. If there is a class of system performance privileged operations, say a dozen or so, you may have a viable argument. > > Well, yes, it is really good that Linux nowadays provides a handful of various > security assuring mechanisms but proper balance is what usually makes valuable > features happen and its users happy and moves forward. > > Gratefully, > Alexey > > [1] https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html
