From: Peter Zijlstra <peterz@infradead.org>
To: Paul Moore <paul@paul-moore.com>
Cc: Ondrej Mosnacek <omosnace@redhat.com>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
selinux@vger.kernel.org, linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org, David Howells <dhowells@redhat.com>,
Matthew Garrett <mjg59@google.com>
Subject: Re: [PATCH] perf/core: fix unconditional security_locked_down() call
Date: Tue, 16 Mar 2021 15:30:46 +0100 [thread overview]
Message-ID: <YFDBFuABYwhKliU9@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CAHC9VhQHrmKHxYuTBOy-JHTXHjGTU9UX-AWk3jbiaNfSkZ+N1A@mail.gmail.com>
On Tue, Mar 16, 2021 at 09:53:21AM -0400, Paul Moore wrote:
> On Wed, Feb 24, 2021 at 4:59 PM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> >
> > Currently, the lockdown state is queried unconditionally, even though
> > its result is used only if the PERF_SAMPLE_REGS_INTR bit is set in
> > attr.sample_type. While that doesn't matter in case of the Lockdown LSM,
> > it causes trouble with the SELinux's lockdown hook implementation.
> >
> > SELinux implements the locked_down hook with a check whether the current
> > task's type has the corresponding "lockdown" class permission
> > ("integrity" or "confidentiality") allowed in the policy. This means
> > that calling the hook when the access control decision would be ignored
> > generates a bogus permission check and audit record.
> >
> > Fix this by checking sample_type first and only calling the hook when
> > its result would be honored.
> >
> > Fixes: b0c8fdc7fdb7 ("lockdown: Lock down perf when in confidentiality mode")
> > Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
> > ---
> > kernel/events/core.c | 12 ++++++------
> > 1 file changed, 6 insertions(+), 6 deletions(-)
>
> Perf/core folks, do you want to pull this in via your tree? If I
> don't hear anything in the next day I'll pull this in via the
> selinux/next tree.
>
> Reviewed-by: Paul Moore <paul@paul-moore.com>
Ah, fell in the cracks... I've no idea what Changelog is trying to tell
me. It is pure gibberish to me. But the patch seems harmless enough to me.
Let me queue it then.
next prev parent reply other threads:[~2021-03-16 14:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-24 21:56 [PATCH] perf/core: fix unconditional security_locked_down() call Ondrej Mosnacek
2021-03-16 13:53 ` Paul Moore
2021-03-16 14:30 ` Peter Zijlstra [this message]
2021-03-16 15:12 ` Paul Moore
2021-03-17 12:38 ` [tip: perf/core] perf/core: Fix " tip-bot2 for Ondrej Mosnacek
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=YFDBFuABYwhKliU9@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=dhowells@redhat.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=mjg59@google.com \
--cc=namhyung@kernel.org \
--cc=omosnace@redhat.com \
--cc=paul@paul-moore.com \
--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