Feature #11281

Enable kASLR

Added by intrigeri 2016-03-24 20:12:42 . Updated 2016-09-20 16:50:05 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Target version:
Tails_2.6
Start date:
2016-03-24
Due date:
% Done:

100%

Feature Branch:
feature/10298-linux-4.x-aufs-kaslr
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

linux (4.5-1~exp1) experimental; urgency=medium

  * [x86] Enable RANDOMIZE_BASE (kASLR). This is incompatible with hibernation,
    so you must use the kernel parameter "kaslr" to enable kASLR and disable
    hibernation at boot time. (Closes: #816067)

Subtasks

Related issues

Blocked by Tails - Feature #10298: Upgrade to Linux 4.x Resolved 2015-08-11

History

#1 Updated by intrigeri 2016-03-24 20:12:58

#2 Updated by intrigeri 2016-06-09 09:06:50

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10
  • Feature Branch set to feature/10298-linux-4.x-aufs-kaslr

Dr_Whax pointed me to an article that explains that kaslr is not as good as one might think (I’m obviously not part of the target audience so I didn’t read it), he and said that 1. spender still thinks the same about the kASLR that landed in Linux 3 years after that post; 2. turning kaslr on may be weak, but shouldn’t harm.

On this ground, I would enable RANDOMIZE_BASE with the kaslr kernel command-line option, once we ship Linux 4.5+, even if it’s not a silver bullet.

co6, jvoisin: thoughts?

#3 Updated by jvoisin 2016-06-09 10:25:50

It doesn’t harm, but it’s useless: public generic bypasses exist :)
But I guess it can annoy/stop kiddies.

#4 Updated by intrigeri 2016-06-10 12:15:29

  • Assignee changed from intrigeri to anonym
  • Target version set to Tails_2.6
  • QA Check set to Ready for QA

I’ve seen all test suite scenarios pass, Jenkins doesn’t particularly dislike it, and I see no blockers left. anonym, how about merging this for 2.6? (note that it’s blocked by Feature #10298 but you might want to review/test/merge both at the same time.)

#5 Updated by cypherpunks 2016-06-12 05:40:15

jvoisin wrote:
> It doesn’t harm, but it’s useless: public generic bypasses exist :)
> But I guess it can annoy/stop kiddies.

It also makes debugging a good bit more irritating, because you have to take the offset into account with every address you get.

#6 Updated by intrigeri 2016-07-15 08:20:11

  • Assignee changed from anonym to intrigeri
  • QA Check deleted (Ready for QA)

I’ll re-run the test suite entirely now that this branch has been upgraded to Linux 4.6.

#7 Updated by intrigeri 2016-07-19 05:17:41

  • Assignee changed from intrigeri to anonym
  • % Done changed from 10 to 50
  • QA Check set to Ready for QA

I’ve seen all test suite scenarios pass eventually, and Jenkins doesn’t seem to particularly dislike this branch, so here we go :)

#8 Updated by intrigeri 2016-08-01 07:36:24

I’d like to ease reviewing for the 2.6 RM, and to get automated tests running about the combination of all these changes ASAP in the 2.6 dev cycle. So, I’ve merged this work, along with the other major branches I’m proposing for 2.6, into the feature/from-intrigeri-for-2.6 integration branch (Jenkins builds and tests.

#9 Updated by anonym 2016-08-23 08:28:02

  • Status changed from In Progress to Fix committed
  • Assignee deleted (anonym)
  • % Done changed from 50 to 100
  • QA Check changed from Ready for QA to Pass

#10 Updated by anonym 2016-09-20 16:50:05

  • Status changed from Fix committed to Resolved