From: Alexey Budankov <alexey.budankov@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Casey Schaufler <casey@schaufler-ca.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Ingo Molnar <mingo@redhat.com>, Jiri Olsa <jolsa@redhat.com>,
Andi Kleen <ak@linux.intel.com>,
elena.reshetova@intel.com,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jann Horn <jannh@google.com>, Kees Cook <keescook@chromium.org>,
Stephane Eranian <eranian@google.com>,
Namhyung Kim <namhyung@kernel.org>,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1 0/3] Introduce CAP_SYS_PERFMON capability for secure Perf users groups
Date: Wed, 11 Dec 2019 20:00:07 +0300 [thread overview]
Message-ID: <72d0dabb-ebd1-f071-6167-1fa935c0a09c@linux.intel.com> (raw)
In-Reply-To: <20191211152435.GN2827@hirez.programming.kicks-ass.net>
On 11.12.2019 18:24, Peter Zijlstra wrote:
> On Wed, Dec 11, 2019 at 01:52:15PM +0300, Alexey Budankov wrote:
>> 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.
>
> You mean this:
>
> da97e18458fb ("perf_event: Add support for LSM and SELinux checks")
>
> ?
Yes, I do.
This feature greatly adds up into MAC access control [1], [2] for perf_events,
additionally to already existing DAC [3]. However, there is still the whole
other part of MAC story on the user space side.
Fortunately MAC and DAC access control mechanisms designed in the way they are
naturally layered and coexist in the system so I don't see any contradiction
in advancing either mechanism to meet the demand of possible diverse use cases.
There is no much rationale in providing favor to one or the other mechanism
because together they constitute complete integrity of security access control
and configurability for diverse use cases of perf_events.
>
>> Then the adoption could also require changes to the installed
>> infrastructure just for the sake of adopting alternative access control mechanism.
>
> This is still very much true.
It is just enough to imaging some HPC cluster or Cloud lab with
several hundreds of nodes to be upgraded.
Thanks,
Alexey
[1] https://en.wikipedia.org/wiki/Security-Enhanced_Linux
[2] https://en.wikipedia.org/wiki/Mandatory_access_control
[3] https://en.wikipedia.org/wiki/Discretionary_access_control
next prev parent reply other threads:[~2019-12-11 17:00 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-05 16:15 [PATCH v1 0/3] Introduce CAP_SYS_PERFMON capability for secure Perf users groups Alexey Budankov
2019-12-05 16:19 ` [PATCH v1 1/3] capabilities: introduce CAP_SYS_PERFMON to kernel and user space Alexey Budankov
2019-12-05 16:21 ` [PATCH v1 2/3] perf/core: apply CAP_SYS_PERFMON to CPUs and kernel monitoring Alexey Budankov
2019-12-05 16:22 ` [PATCH v1 3/3] perf tool: extend Perf tool with CAP_SYS_PERFMON support Alexey Budankov
2019-12-05 16:49 ` [PATCH v1 0/3] Introduce CAP_SYS_PERFMON capability for secure Perf users groups Casey Schaufler
2019-12-05 17:05 ` Alexey Budankov
2019-12-05 17:33 ` Casey Schaufler
2019-12-05 18:11 ` Andi Kleen
2019-12-05 18:37 ` Alexey Budankov
2019-12-11 10:52 ` Alexey Budankov
2019-12-11 15:24 ` Peter Zijlstra
2019-12-11 17:00 ` Alexey Budankov [this message]
2019-12-11 18:09 ` Casey Schaufler
2019-12-11 20:36 ` Andi Kleen
2019-12-11 21:25 ` Casey Schaufler
2019-12-12 14:24 ` Stephen Smalley
2019-12-15 11:53 ` Alexey Budankov
2019-12-11 19:04 ` Stephane Eranian
-- strict thread matches above, loose matches on Subject: below --
2019-12-05 15:41 Alexey Budankov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=72d0dabb-ebd1-f071-6167-1fa935c0a09c@linux.intel.com \
--to=alexey.budankov@linux.intel.com \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=casey@schaufler-ca.com \
--cc=elena.reshetova@intel.com \
--cc=eranian@google.com \
--cc=jannh@google.com \
--cc=jolsa@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=selinux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).