All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Corbet <corbet@lwn.net>
To: Alexey Budankov <alexey.budankov@linux.intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Kees Cook <keescook@chromium.org>, Jann Horn <jannh@google.com>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Andi Kleen <ak@linux.intel.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Tvrtko Ursulin <tursulin@ursulin.net>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	"kernel-hardening@lists.openwall.com" 
	<kernel-hardening@lists.openwall.com>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>
Subject: Re: [PATCH v2 1/2] Documentation/admin-guide: introduce perf-security.rst file
Date: Mon, 26 Nov 2018 13:28:33 -0700	[thread overview]
Message-ID: <20181126132833.5302688b@lwn.net> (raw)
In-Reply-To: <02dbd6dc-86b5-2307-4122-b716c51b9eaa@linux.intel.com>

On Mon, 26 Nov 2018 11:57:21 +0300
Alexey Budankov <alexey.budankov@linux.intel.com> wrote:

> >> +For the purpose of performing security checks Linux implementation splits
> >> +processes into two categories [6]_ : a) privileged processes (whose effective
> >> +user ID is 0, referred to as superuser or root), and b) unprivileged processes
> >> +(whose effective UID is nonzero).  
> > 
> > Is that really what's going on here?  If I understand things correctly,
> > it's looking for CAP_SYS_PTRACE rather than a specific UID; am I missing
> > something here?  
> 
> You are right regarding CAP_SYS_PTRACE but this capability is not the only 
> one which is used by perf_events for security checks, so the capabilities 
> clarification is kept aside of these patches, because patches initial intention 
> is to clarify security specifics of sysctl_perf_even_paranoid settings.
> 
> I agree that the document can be extended with details clarifying capabilities 
> used by perf_events for security checks.

I don't really like the idea of adding a document that we know doesn't
really describe how the security decision is made.  Even a one-line
parenthetical saying that things are more complicated and giving a pointer
to a place to look for details would help, IMO.

Either way, I can merge this, but I'd like to have an ack from the perf
folks first.

Thanks,

jon

  reply	other threads:[~2018-11-26 20:28 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-21  8:57 [PATCH v2 0/2] Documentation/admin-guide: introduce perf-security.rst file and extend perf_event_paranoid documentation Alexey Budankov
2018-11-21  8:57 ` Alexey Budankov
2018-11-21  9:14 ` [PATCH v2 1/2] Documentation/admin-guide: introduce perf-security.rst file Alexey Budankov
2018-11-21  9:14   ` Alexey Budankov
2018-11-25 19:47   ` Jonathan Corbet
2018-11-25 19:47     ` Jonathan Corbet
2018-11-26  8:57     ` Alexey Budankov
2018-11-26  8:57       ` Alexey Budankov
2018-11-26 20:28       ` Jonathan Corbet [this message]
2018-11-26 20:28         ` Jonathan Corbet
2018-11-27  6:55         ` Alexey Budankov
2018-11-27  6:55           ` Alexey Budankov
2018-11-21  9:15 ` [PATCH v2 2/2] Documentation/admin-guide: update admin-guide index.rst Alexey Budankov
2018-11-21  9:15   ` Alexey Budankov
  -- strict thread matches above, loose matches on Subject: below --
2018-11-20  9:21 [PATCH v2 0/2]: Documentation/admin-guide: introduce perf-security.rst file and extend perf_event_paranoid documentation Alexey Budankov
2018-11-20  9:27 ` [PATCH v2 1/2] Documentation/admin-guide: introduce perf-security.rst file Alexey Budankov
2018-11-20  9:27   ` 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=20181126132833.5302688b@lwn.net \
    --to=corbet@lwn.net \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=alexey.budankov@linux.intel.com \
    --cc=jannh@google.com \
    --cc=jolsa@redhat.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=tursulin@ursulin.net \
    /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.