[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 17 Jun 2016 08:56:46 +0300
From: Alexander Shishkin <alexander.shishkin@...ux.intel.com>
To: Ben Hutchings <ben@...adent.org.uk>, linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH 2/2] security,perf: Allow further restriction of perf_event_open
Ben Hutchings <ben@...adent.org.uk> writes:
> When kernel.perf_event_open is set to 3 (or greater), disallow all
> access to performance events by users without CAP_SYS_ADMIN.
> Add a Kconfig symbol CONFIG_SECURITY_PERF_EVENTS_RESTRICT that
> makes this value the default.
So this patch does two things, can it then be made into two patches?
>
> This is based on a similar feature in grsecurity
> (CONFIG_GRKERNSEC_PERF_HARDEN). This version doesn't include making
> the variable read-only. It also allows enabling further restriction
> at run-time regardless of whether the default is changed.
This paragraph doesn't seem to belong in the commit message.
What this commit message is missing entirely is the rationale behind
this change other than "grsecurity does the same". Can you please
elaborate?
> Signed-off-by: Ben Hutchings <ben@...adent.org.uk>
> ---
> I made a similar change to Debian's kernel packages in August,
> including the more restrictive default, and no-one has complained yet.
As a debian user, is this a good place to complain? Because it does get
it the way.
Thanks,
--
Alex
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
