Message-ID: <16e9e399-2ebf-261f-eee5-cf9ace2a82b9@schaufler-ca.com>
Date:   Wed, 11 Dec 2019 10:09:30 -0800
From:   Casey Schaufler <casey@...aufler-ca.com>
To:     Alexey Budankov <alexey.budankov@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Ingo Molnar <mingo@...hat.com>
Cc:     Jiri Olsa <jolsa@...hat.com>, Andi Kleen <ak@...ux.intel.com>,
        elena.reshetova@...el.com,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jann Horn <jannh@...gle.com>,
        Kees Cook <keescook@...omium.org>,
        Stephane Eranian <eranian@...gle.com>,
        Namhyung Kim <namhyung@...nel.org>,
        linux-security-module@...r.kernel.org, selinux@...r.kernel.org,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [PATCH v1 0/3] Introduce CAP_SYS_PERFMON capability for secure
 Perf users groups

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

Powered by blists - more mailing lists