All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Fernandes <joel@joelfernandes.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	primiano@google.com, rsavitski@google.com, jeffv@google.com,
	kernel-team@android.com, Alexei Starovoitov <ast@kernel.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	bpf@vger.kernel.org, Daniel Borkmann <daniel@iogearbox.net>,
	Ingo Molnar <mingo@redhat.com>, James Morris <jmorris@namei.org>,
	Jiri Olsa <jolsa@redhat.com>, Kees Cook <keescook@chromium.org>,
	linux-security-module@vger.kernel.org,
	Matthew Garrett <matthewgarrett@google.com>,
	Namhyung Kim <namhyung@kernel.org>,
	selinux@vger.kernel.org, Song Liu <songliubraving@fb.com>,
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
	<x86@kernel.org>, Yonghong Song <yhs@fb.com>
Subject: Re: [PATCH RFC] perf_event: Add support for LSM and SELinux checks
Date: Fri, 11 Oct 2019 11:47:34 -0400	[thread overview]
Message-ID: <20191011154734.GA105106@google.com> (raw)
In-Reply-To: <20191011070543.GV2328@hirez.programming.kicks-ass.net>

On Fri, Oct 11, 2019 at 09:05:43AM +0200, Peter Zijlstra wrote:
> On Thu, Oct 10, 2019 at 02:31:14PM -0400, Joel Fernandes wrote:
> > On Thu, Oct 10, 2019 at 07:09:49PM +0200, Peter Zijlstra wrote:
> 
> > > Yes, I did notice, I found it weird.
> > > 
> > > If you have CAP_IPC_LIMIT you should be able to bust mlock memory
> > > limits, so I don't see why we should further relate that to paranoid.
> > > 
> > > The way I wrote it, we also allow to bust the limit if we have disabled
> > > all paranoid checks. Which makes some sense I suppose.
> > > 
> > > The original commit is this:
> > > 
> > >   459ec28ab404 ("perf_counter: Allow mmap if paranoid checks are turned off")
> > 
> > I am thinking we can just a new function perf_is_paranoid() that has nothing
> > to do with the CAP_SYS_ADMIN check and doesn't have tracepoint wording:
> > 
> > static inline int perf_is_paranoid(void)
> > {
> > 	return sysctl_perf_event_paranoid > -1;
> > }
> > 
> > And then call that from the mmap() code:
> > if (locked > lock_limit && perf_is_paranoid() && !capable(CAP_IPC_LOCK)) {
> > 	return -EPERM;
> > }
> > 
> > I don't think we need to add selinux security checks here since we are
> > already adding security checks earlier in mmap(). This will make the code and
> > its intention more clear and in line with the commit 459ec28ab404 you
> > mentioned. Thoughts?
> 
> Mostly that I'm confused by the current code ;-)
> 
> Like I said, CAP_IPC_LIMIT on its own should already allow busting the
> limit, I don't really see why we should make it conditional on paranoid.
> 
> But if you want to preserve behaviour (arguably a sane thing for your
> patch) then yes, feel free to do as you propose.

Ok, I will do it as I proposed above and resend patch today. Thanks!

 - Joel


      reply	other threads:[~2019-10-11 15:47 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-09 20:36 [PATCH RFC] perf_event: Add support for LSM and SELinux checks Joel Fernandes (Google)
2019-10-09 21:55 ` Casey Schaufler
2019-10-09 22:14   ` James Morris
2019-10-09 22:41     ` Casey Schaufler
2019-10-10  0:40       ` Joel Fernandes
2019-10-10  0:53         ` Casey Schaufler
2019-10-10  2:44       ` James Morris
2019-10-10 18:12         ` Casey Schaufler
2019-10-10 19:41           ` James Morris
2019-10-09 22:11 ` James Morris
2019-10-10  0:43   ` Joel Fernandes
2019-10-10  7:23 ` Alexey Budankov
2019-10-10  8:12 ` Peter Zijlstra
2019-10-10 15:13   ` Joel Fernandes
2019-10-10 17:09     ` Peter Zijlstra
2019-10-10 18:31       ` Joel Fernandes
2019-10-11  7:05         ` Peter Zijlstra
2019-10-11 15:47           ` Joel Fernandes [this message]

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=20191011154734.GA105106@google.com \
    --to=joel@joelfernandes.org \
    --cc=acme@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=jeffv@google.com \
    --cc=jmorris@namei.org \
    --cc=jolsa@redhat.com \
    --cc=keescook@chromium.org \
    --cc=kernel-team@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=matthewgarrett@google.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=primiano@google.com \
    --cc=rostedt@goodmis.org \
    --cc=rsavitski@google.com \
    --cc=selinux@vger.kernel.org \
    --cc=songliubraving@fb.com \
    --cc=x86@kernel.org \
    --cc=yhs@fb.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.