Project

General

Profile

Feature #12107

Feature #7649: Include a grsecurity-patched kernel

Can PAX_MEMORY_SANITIZE replace memory erasure on shutdown?

Added by intrigeri almost 3 years ago. Updated over 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
01/02/2017
Due date:
% Done:

100%

Feature Branch:
Type of work:
Research
Blueprint:
Starter:
Yes
Affected tool:

Description

grsec sanitizes all freed memory.

As explained in #7649#note-40, this breaks the tests that exercise our memory erasure on shutdown, but might actually allow us to drop that feature... which would be good given the lack of robustness it has historically had, that has even gotten worse recently.

So, is there anything that our current kexec-based implementation wipes, but that wouldn't be erased by PAX_MEMORY_SANITIZE?


Related issues

Related to Tails - Feature #12397: Evaluate how kernel memory poisoning works for tmpfs Resolved 03/20/2017
Related to Tails - Feature #12398: Evaluate how kernel memory poisoning works for disk cache Resolved 03/20/2017

History

#1 Updated by intrigeri almost 3 years ago

  • Description updated (diff)

#2 Updated by intrigeri almost 3 years ago

If it helps, I can provide post-shutdown Tails memory dumps done with our current implementation on the one hand, and with the grsec kernel on the other hand.

#4 Updated by intrigeri almost 3 years ago

Oops, I forgot to ask about tmpfs data. I'll ask as a follow-up after pipacs answers my initial questions.

#5 Updated by intrigeri almost 3 years ago

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10

#6 Updated by cypherpunks almost 3 years ago

It looks like kexecing into another grsecurity-enabled kernel will trigger PAX_MEMORY_SANITIZE to wipe in-use memory.

From pipacs:

i'd like to interject here and point out a less than obvious sideeffect
of SANITIZE (not really documented because the effect isn't relevant
for the original purpose of SANITIZE): when the kernel transitions
from the bootmem allocator to the buddy allocator during early boot,
it does so by simulating a free of all that memory back to the buddy
allocator. this in turn activates the erase-on-free logic of SANITIZE
pretty much for free (pun intended, sorry).

in other words, if you were to kexec into a SANITIZE enabled kernel,
you'd get your memory clearing for free automatically, earlier than
any initramfs would execute even and it'd cover most kernel memory
that the kernel ever cares about (or cared in its previous incarnation
at least).

Though he makes one mistaken assumption:

yes if (presumably :) you meant a clean shutdown (and subject to
the above details). i'm just pointing it out because in the panic
case you mentioned a clean shutdown may not be possible.

Even the current kexec method won't accomplish its goal in an unclean shutdown.

#7 Updated by cypherpunks almost 3 years ago

In order to disable whitelisted slabs, we'll want to add pax_sanitize_slab=full to the kernel command line.

Some slabs are not sanitized for technical reasons. If freeing of a slab is deferred to RCU with via SLAB_DESTROY_BY_RCU (which frees the object immediately, but delays the freeing of the pages by a grace period), then it cannot be sanitized by PaX. This includes some slabs related to networking, and the cache which holds the table of process signal handlers.

#8 Updated by intrigeri almost 3 years ago

Even the current kexec method won't accomplish its goal in an unclean shutdown.

Do you mean in current Tails, or once we have a grsec kernel?

#9 Updated by cypherpunks almost 3 years ago

intrigeri wrote:

Even the current kexec method won't accomplish its goal in an unclean shutdown.

Do you mean in current Tails, or once we have a grsec kernel?

Current Tails. You can't kexec if you get a kernel panic, power outage, triple exception fault, nuclear war blows your computer into smithereens, etc. I think pipacs just misunderstood our panic scenario, which is technically still a clean shutdown from the operating system's point of view (i.e. it gets to stop services, kill remaining processes, flush the disk, etc).

#10 Updated by intrigeri almost 3 years ago

I think pipacs just misunderstood our panic scenario, which is technically still a clean shutdown from the operating system's point of view (i.e. it gets to stop services, kill remaining processes, flush the disk, etc).

Well, not exactly: you're correct that a shutdown triggered via the GNOME interface is a clean one, but an emergency one, triggered by pulling out the boot medium, is not clean (see config/chroot_local-includes/usr/local/lib/udev-watchdog-wrapper in our Git tree for details), so PAX_MEMORY_SANITIZE won't do much for us in that case.

#11 Updated by cypherpunks almost 3 years ago

intrigeri wrote:

I think pipacs just misunderstood our panic scenario, which is technically still a clean shutdown from the operating system's point of view (i.e. it gets to stop services, kill remaining processes, flush the disk, etc).

Well, not exactly: you're correct that a shutdown triggered via the GNOME interface is a clean one, but an emergency one, triggered by pulling out the boot medium, is not clean (see config/chroot_local-includes/usr/local/lib/udev-watchdog-wrapper in our Git tree for details), so PAX_MEMORY_SANITIZE won't do much for us in that case.

It's still clean enough that it allows kexecing into a new kernel, right? After all, memlockd is provided to lock the necessary files in memory so there will be no page faults when the process tries to access resources needed to shut down when the drive is no longer present. As long as it can kexec into a new kernel, PAX_MEMORY_SANITIZE should work. If it can't, then the memlockd configuration should be improved.

#12 Updated by intrigeri over 2 years ago

  • Related to Feature #12089: Enable the kernel page allocator poisoning added

#13 Updated by intrigeri over 2 years ago

  • Related to Bug #12354: Fix shutdown and memory wipe regressions on 3.0~betaN added

#14 Updated by intrigeri over 2 years ago

intrigeri wrote:

Oops, I forgot to ask about tmpfs data.

Actually, we can test this ourselves pretty easily, by filling a tmpfs with a known pattern, unmounting the tmpfs, and looking for the pattern in memory.

#15 Updated by intrigeri over 2 years ago

Also, I'll probably repurpose this ticket soonish to cover poisoning features found in mainline Linux (#12089 and #12090) as well.

#16 Updated by intrigeri over 2 years ago

  • Related to deleted (Bug #12354: Fix shutdown and memory wipe regressions on 3.0~betaN)

#17 Updated by intrigeri over 2 years ago

  • Related to deleted (Feature #12089: Enable the kernel page allocator poisoning)

#18 Updated by intrigeri over 2 years ago

  • Related to Feature #12397: Evaluate how kernel memory poisoning works for tmpfs added

#19 Updated by intrigeri over 2 years ago

  • Related to Feature #12398: Evaluate how kernel memory poisoning works for disk cache added

#20 Updated by intrigeri over 2 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 10 to 100

The automated tests written for #12397 and #12398 confirm that mainline's poisoning is good enough for our needs, so this is now orthogonal to grsec. See next steps on #12354.

Also available in: Atom PDF