Tails

#2 Updated by intrigeri 2017-01-02 12:13:20

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.

#3 Updated by intrigeri 2017-01-02 14:27:51

Asked pipacs (PaX Team): https://mailman.boum.org/pipermail/tails-dev/2017-January/011128.html.

#4 Updated by intrigeri 2017-01-02 14:32:48

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

#6 Updated by cypherpunks 2017-01-06 02:44:28

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 2017-01-06 03:15:01

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 2017-01-06 08:53:44

> 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 2017-01-07 09:04:40

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 2017-01-17 09:15:39

> 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 2017-01-20 07:49:33

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.

#14 Updated by intrigeri 2017-03-18 17:09:25

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 2017-03-18 17:11:07

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