Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1424686 > unrolled thread
| Started by | Alexander Shishkin <alexander.shishkin@linux.intel.com> |
|---|---|
| First post | 2016-06-17 08:00 +0200 |
| Last post | 2016-06-17 17:30 +0200 |
| Articles | 3 — 3 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH 2/2] security,perf: Allow further restriction of perf_event_open Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2016-06-17 08:00 +0200
Re: [PATCH 2/2] security,perf: Allow further restriction of perf_event_open Ben Hutchings <ben@decadent.org.uk> - 2016-06-17 14:20 +0200
Re: [kernel-hardening] Re: [PATCH 2/2] security,perf: Allow further restriction of perf_event_open Daniel Micay <danielmicay@gmail.com> - 2016-06-17 17:30 +0200
| From | Alexander Shishkin <alexander.shishkin@linux.intel.com> |
|---|---|
| Date | 2016-06-17 08:00 +0200 |
| Subject | Re: [PATCH 2/2] security,perf: Allow further restriction of perf_event_open |
| Message-ID | <rKUYV-2vY-5@gated-at.bofh.it> |
Ben Hutchings <ben@decadent.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@decadent.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
[toc] | [next] | [standalone]
| From | Ben Hutchings <ben@decadent.org.uk> |
|---|---|
| Date | 2016-06-17 14:20 +0200 |
| Subject | Re: [PATCH 2/2] security,perf: Allow further restriction of perf_event_open |
| Message-ID | <rL0UF-6pR-3@gated-at.bofh.it> |
| In reply to | #1424686 |
[Multipart message — attachments visible in raw view] — view raw
On Fri, 2016-06-17 at 08:56 +0300, Alexander Shishkin wrote: > Ben Hutchings <ben@decadent.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? It could. > > > > 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. I'm giving credit where credit is due. > What this commit message is missing entirely is the rationale behind > this change other than "grsecurity does the same". Can you please > elaborate? It allows disabling a facility which in many systems is not needed and is only a security risk. > > Signed-off-by: Ben Hutchings <ben@decadent.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. OK, then you're the first one. And you know how to change this, don't you? Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus
[toc] | [prev] | [next] | [standalone]
| From | Daniel Micay <danielmicay@gmail.com> |
|---|---|
| Date | 2016-06-17 17:30 +0200 |
| Subject | Re: [kernel-hardening] Re: [PATCH 2/2] security,perf: Allow further restriction of perf_event_open |
| Message-ID | <rL3Sx-8fe-17@gated-at.bofh.it> |
| In reply to | #1424686 |
[Multipart message — attachments visible in raw view] — view raw
> As a debian user, is this a good place to complain? Because it does > get > it the way. It would be relevant to whether or not it should be set to 3 by default in the kernel without explicit configuration, but there's no proposal to do that. Debian has to pick a trade-off beyond security and a tiny roadblock for developers. It's not always the case though. In Android, there's userspace integration allowing it to be toggled by the Android Debugging Bridge shell user so profiling tools are being taught to automatically toggle it. Enabling ADB and then using it for profiling is an implicit opt-in.
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web