Feature #11421

Change kernel.perf_event_paranoid sysctl to 2

Added by cypherpunks 2016-05-15 18:55:36 . Updated 2016-07-21 06:51:49 .

Status:
Rejected
Priority:
Normal
Assignee:
Category:
Target version:
Start date:
2016-05-15
Due date:
% Done:

0%

Feature Branch:
feature/11421-Change-kernel.perf_event_paranoid-sysctl-2
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

From the kernel documentation on core kernel sysctls:

perf_event_paranoid:

Controls use of the performance events system by unprivileged
users (without CAP_SYS_ADMIN).  The default value is 1.

 -1: Allow use of (almost) all events by all users
>=0: Disallow raw tracepoint access by users without CAP_IOC_LOCK
>=1: Disallow CPU event access by users without CAP_SYS_ADMIN
>=2: Disallow kernel profiling by users without CAP_SYS_ADMIN

The current default value for the Tails kernel.perf_event_paranoid sysctl is 1 (the Debian default). This means that kernel profiling is enabled for all users, even without CAP_SYS_ADMIN. The perf subsystem has a huge history of privesc vunerabilities. I propose we change this sysctl to 2, as Tails users do not need to do kernel profiling as a the amnesia user. This will be as simple as creating a file, /etc/sysctl.d/perf_event_paranoid.conf, containing the value kernel.perf_event_paranoid=2.


Subtasks


Related issues

Related to Tails - Feature #11511: Drop custom value for kernel.perf_event_paranoid sysctl Resolved 2016-06-04

History

#1 Updated by Dr_Whax 2016-05-17 22:04:32

  • Assignee set to Dr_Whax

#2 Updated by intrigeri 2016-05-23 12:01:17

> I propose we change this sysctl to 2, as Tails users do not need to do kernel profiling as a the amnesia user.

co6, jvoisin, DrWhax: thoughts, opinions?

I am not much skilled in this field, but this makes sense to me, especially since it’s the default in newer Debian kernels:

linux (4.1.3-1) unstable; urgency=medium
[...]
 * security: Apply and enable GRKERNSEC_PERF_HARDEN feature from Grsecurity,
disabling use of perf_event_open() by unprivileged users by default
(sysctl: kernel.perf_event_paranoid)

… which introduces a new value (3), that is now the default in current Linux 4.x on Debian.

So if we manually set it to 2 now, once we upgrade Linux to 4.x (Feature #10298, timeline is unclear) we’ll need to revert this customization, otherwise it would prevent us from benefiting from the new default.

#3 Updated by intrigeri 2016-05-23 12:01:32

#4 Updated by co6 2016-05-23 17:05:30

Hi,

I’m not an expert either, but I can’t think of a reason not to change the value to 2.
For reference:
the commit message turning the pref to 2 in the linux kernel: https://github.com/torvalds/linux/commit/0161028b7c8aebef64194d3d73e43bc3b53b5c66

#5 Updated by intrigeri 2016-05-23 19:17:29

> For reference: the commit message turning the pref to 2 in the linux kernel:

(JFTR: that commit made it into Linux 4.6.)

#6 Updated by intrigeri 2016-05-23 19:17:45

> I’m not an expert either, but I can’t think of a reason not to change the value to 2.

Thank you! I might prepare a branch that does that one of these days, and we’ll see how our test suite likes it (I don’t see why they couldn’t be friends, but who knows :)

#7 Updated by intrigeri 2016-05-23 22:08:26

  • Status changed from New to Confirmed

> I might prepare a branch that does that one of these days, […]

Actually I realized that DrWhax set himself as the assignee, so I won’t steal it from him :)

#8 Updated by cypherpunks 2016-05-24 02:17:14

Is it possible to have the sysctl config contain something like:

kernel.perf_event_paranoid=2
kernel.perf_event_paranoid=3

So it sets it to 2, then tries to set it to 3? On the current kernel, it’ll set it to 2, and then will fail at setting it to 3, because that option doesn’t exist. When Tails upgrades to 4.x, then it’ll set it to 2, and then successfully bump it up to 3, so there won’t be a risk of making a mistake and keeping it at 2, preventing the default of 3 from taking effect.

#9 Updated by Dr_Whax 2016-06-04 00:12:57

  • % Done changed from 0 to 20
  • Feature Branch set to feature/11421-Change-kernel.perf_event_paranoid-sysctl-2

cypherpunks wrote:
> Is it possible to have the sysctl config contain something like:
>
> […]
>
> So it sets it to 2, then tries to set it to 3? On the current kernel, it’ll set it to 2, and then will fail at setting it to 3, because that option doesn’t exist. When Tails upgrades to 4.x, then it’ll set it to 2, and then successfully bump it up to 3, so there won’t be a risk of making a mistake and keeping it at 2, preventing the default of 3 from taking effect.

I have prepared a branch!

If my branch is good and gets merged. I’ll create a new sub-ticket for changing the value to kernel.perf_event_paranoid=3 when we have a kernel in the 4.x range.(Feature #10298)

#10 Updated by Dr_Whax 2016-06-04 00:13:34

  • Assignee changed from Dr_Whax to intrigeri
  • QA Check set to Ready for QA

#11 Updated by intrigeri 2016-06-04 14:06:58

  • Assignee changed from intrigeri to Dr_Whax
  • QA Check changed from Ready for QA to Dev Needed

> I have prepared a branch!

Cool! Code review passes (unsurprisingly). Pushed to the official repo so Jenkins tells us how it goes :)

> If my branch is good and gets merged. I’ll create a new sub-ticket for changing the value to kernel.perf_event_paranoid=3 when we have a kernel in the 4.x range.(Feature #10298)

Good. Please reassign to me once this is done (as a subtask of Feature #10298), as I don’t want to take any risk of merging this branch without having the follow-up ticket ready.

#12 Updated by Dr_Whax 2016-06-04 21:28:11

  • Assignee changed from Dr_Whax to intrigeri

intrigeri wrote:
> > I have prepared a branch!
>
> Cool! Code review passes (unsurprisingly). Pushed to the official repo so Jenkins tells us how it goes :)

Cheers!

>
> > If my branch is good and gets merged. I’ll create a new sub-ticket for changing the value to kernel.perf_event_paranoid=3 when we have a kernel in the 4.x range.(Feature #10298)
>
> Good. Please reassign to me once this is done (as a subtask of Feature #10298), as I don’t want to take any risk of merging this branch without having the follow-up ticket ready.

Done, see here: https://labs.riseup.net/code/issues/11511

#13 Updated by intrigeri 2016-06-06 05:00:54

#14 Updated by intrigeri 2016-06-06 05:00:58

  • related to Feature #11511: Drop custom value for kernel.perf_event_paranoid sysctl added

#15 Updated by intrigeri 2016-06-06 05:02:14

  • QA Check changed from Dev Needed to Ready for QA

> Done, see here: https://labs.riseup.net/code/issues/11511

Thanks. Note that I really meant as a subtask of Feature #10298, so I’ve adjusted the Redmine stuff.

#16 Updated by intrigeri 2016-06-06 05:04:17

  • Status changed from Confirmed to In Progress
  • Assignee changed from intrigeri to anonym
  • Target version set to Tails_2.6
  • QA Check changed from Ready for QA to Dev Needed

Let’s not do that in a point-release (that has no RC).

#17 Updated by intrigeri 2016-06-06 05:04:37

  • QA Check changed from Dev Needed to Ready for QA

#18 Updated by intrigeri 2016-06-07 02:52:45

Dr_Whax: I suspect that anonym will ask you to update wiki/src/contribute/design/kernel_hardening.mdwn accordingly, so perhaps do it now in order to avoid one round-trip :)

#19 Updated by anonym 2016-06-14 12:36:56

intrigeri wrote:
> Dr_Whax: I suspect that anonym will ask you to update wiki/src/contribute/design/kernel_hardening.mdwn accordingly, so perhaps do it now in order to avoid one round-trip :)

No need for this, given that we’ll actually use Debian’s default configuration soon (see Feature #11511).

#20 Updated by intrigeri 2016-07-21 06:51:49

  • Status changed from In Progress to Rejected
  • Assignee deleted (anonym)
  • Target version deleted (Tails_2.6)
  • % Done changed from 20 to 0
  • QA Check deleted (Ready for QA)

I’ve merged this branch into the one for Feature #10298, that’s ready for QA, so I don’t think it’s worth tracking this one separately :)