Feature #10951

Remove kernel .map files

Added by anonym 2016-01-16 15:06:30 . Updated 2016-06-08 01:25:17 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Target version:
Tails_2.4
Start date:
2016-01-16
Due date:
% Done:

100%

Feature Branch:
feature/10951-remove-kernel-map-files
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

We currently ship files like /boot/System.map-${KERNEL_VERSION}-${ARCH} which contains the memory addresses of kernel functions, making the life of malware a bit easier.

We should remove these, since their only purpose is kernel debugging (right?), and they increase the Tails image size (uncompressed the two we have are ~4.5 MiB).

Subtasks

History

#1 Updated by anonym 2016-01-16 15:07:27

Actually, upstream Debian should perhaps split them into separate -dbg packages?

#2 Updated by intrigeri 2016-01-16 15:33:46

  • Assignee set to anonym

I think the security argument is pretty weak, given 1. we use standard Debian kernels, whose symbols’ address is public information; 2. there are tools like https://github.com/jonoberheide/ksymhunter around. Still, every small bit we do to make exploitation easier is welcome, I guess.

I’m fine with removing them on the grounds that it’ll save ISO & IUK size.

anonym: assigning to you since you set a target version; if you don’t want it, then either drop the target version, or find a volunteer :)

#3 Updated by anonym 2016-02-16 18:06:25

intrigeri wrote:
> I think the security argument is pretty weak, given 1. we use standard Debian kernels, whose symbols’ address is public information;

Of course — the original (private) bug report made the case that off the shelf malware might not have this info bundled, so this increases the size or complexity (if it has to identify what to fetch from some public source) a bit, which doesn’t hurt. :)

> 2. there are tools like https://github.com/jonoberheide/ksymhunter around.

Yeah, yeah… :)

> I’m fine with removing them on the grounds that it’ll save ISO & IUK size.

Any decrease in the cruft we ship is a welcome change in itself, imho.

> anonym: assigning to you since you set a target version; if you don’t want it, then either drop the target version, or find a volunteer :)

I’ll keep it.

#4 Updated by anonym 2016-02-16 18:08:31

  • % Done changed from 0 to 10
  • Type of work changed from Research to Code

I do not really see why this needs any research. Imprementation-wise we to do rm -f /boot/*.map /boot/*.map-* in some appropriate hook.

#5 Updated by anonym 2016-02-16 18:10:21

  • Status changed from Confirmed to In Progress

Applied in changeset commit:fa62a46eb21b509f28aabcf4df0101e1a37a1cc9.

#6 Updated by anonym 2016-02-16 18:11:17

  • Assignee deleted (anonym)
  • % Done changed from 10 to 40
  • Feature Branch set to feature/10951-remove-kernel-map-files

Untested.

#7 Updated by anonym 2016-02-16 18:55:15

  • % Done changed from 40 to 50
  • QA Check set to Ready for QA

Tested now. It works as it should, i.e. the .map files are removed, but the truncation we do on the resulting ISO image made the resulting image the same size as the previous devel one I built. :)

#8 Updated by anonym 2016-02-24 18:54:04

  • Assignee set to intrigeri

I doubt there’s any one else that will take this one than you, intro. :S

Given the limited scope of this branch, I’d happily give it a freeze exception and get it into the final 2.2 image. Perhaps you can just throw it into the mix when automatically testing some other branch? Otherwise, unassign yourself and we deal with it later, possibly even for 2.3 (imho cleanups like this is more of a bugfix than a feature).

#9 Updated by intrigeri 2016-02-26 11:37:43

  • Assignee deleted (intrigeri)

anonym wrote:
> I doubt there’s any one else that will take this one than you, intro. :S

I won’t have time to deal with this for 2.2, and not sure about 2.3, especially since I’ve taken over some more reviewing duties that were initially assigned to someone else. I suggest you ask other people to book some time for reviews for the next cycle (actually, until 2.5 included).

#10 Updated by anonym 2016-03-15 11:25:48

  • Target version changed from Tails_2.2 to Tails_2.3

#11 Updated by cypherpunks 2016-04-22 00:36:44

If you remove these files, make sure the kernel.kptr_restrict sysctl is set to 2, otherwise it’s almost completely pointless.

#12 Updated by intrigeri 2016-04-26 02:22:52

  • Assignee set to anonym
  • Target version changed from Tails_2.3 to Tails_2.4
  • QA Check changed from Ready for QA to Dev Needed

> If you remove these files, make sure the kernel.kptr_restrict sysctl is set to 2, otherwise it’s almost completely pointless.

anonym, can you please give it a look?

#13 Updated by anonym 2016-05-13 07:23:10

  • % Done changed from 50 to 60

intrigeri wrote:
> > If you remove these files, make sure the kernel.kptr_restrict sysctl is set to 2, otherwise it’s almost completely pointless.
>
> anonym, can you please give it a look?

I had a look, and it makes sense, see commit:5243e64 for details; personally I mostly wanted this for removing cruft, but if this change doesn’t break anything for us, why not? :) Let’s see how the automated test suite runs fare.

#14 Updated by cypherpunks 2016-05-14 19:25:38

Now we just have to write a kernel module to hook into the uname() syscall so it doesn’t leak the kernel we’re using, so an attacker can’t just download the corresponding .map files online. ;)

But in all seriousness, it does sound like a good idea. At least it increases the price of exploits, because out-of-the-box exploits are less likely to work, and many of the adversaries of Tails users will be using cheap exploits that simply check for /proc/kallsyms and /boot/System.map, and then bail if they don’t exist.

#15 Updated by anonym 2016-05-15 04:14:04

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

cypherpunks wrote:
> Now we just have to write a kernel module to hook into the uname() syscall so it doesn’t leak the kernel we’re using, so an attacker can’t just download the corresponding .map files online. ;)

Even better: what if it faked the wrong version (e.g. randomly picked on boot) for extra confusion? :)

> But in all seriousness, it does sound like a good idea. At least it increases the price of exploits, because out-of-the-box exploits are less likely to work, and many of the adversaries of Tails users will be using cheap exploits that simply check for /proc/kallsyms and /boot/System.map, and then bail if they don’t exist.

Agreed. We’ll merge this as long as there are no truly legit use cases for having these available in Tails, which seems highly likely.

This branch has passed the automated test suite on Jenkins, and I just pushed a corresponding design update. intrigeri, since you already has been involved on this ticket, can you do the review’n’merge?

#16 Updated by intrigeri 2016-05-16 12:27:33

  • % Done changed from 60 to 70

Code review passes, I’ll quickly build, test and hopefully merge.

#17 Updated by intrigeri 2016-05-16 13:21:13

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

merged!

#18 Updated by anonym 2016-06-08 01:25:17

  • Status changed from Fix committed to Resolved