Re: [Tails-dev] What is *not* erased (after shutdown) with P…

Hi everybody!

Harlan Lieberman-Berg:
> Thanks for weighing in, PaX Team. (And thank you for the awesome you
> and spender do on kernel security!)

+1 :)

> To summarize, it seems that we have a couple different options to choose
> from:

> * Switch to a dedicated microkernel that does a memory wipe, and kexec
> into it. This could be something custom, or an enhancement of the
> preexisting solution.

> Advantages are that it will (probably) give us the most clean wipe, as
> we can reduce the amount of space the kernel takes up and drop all
> functionality that's not absolutely needed. On the negative side, it
> will require continuing to support a separate codeline that's not
> going to be reused elsewhere, limiting testing and development
> effort. It also requires us to reenable kexec functionality, which
> exposes a risk of code injection unless we get signed kexec support.

> * Rely on PAX_MEMORY_SANITIZE. This either takes the form of enhancing
> cleaning memory on shutdown, or kexec'ing into the same version of the
> kernel that's already running to rely on the buddy allocator clearing
> everything again.

> Definite pro in that it reduces the amount of code maintained
> downstream by the Tails team to ~zero. Cons are increased reliance on
> more complex functionality in the kernel, and potentially relying on a
> somewhat undocumented and unplanned functionality in the kernel. (It
> seems unlikely that it'll change any time without us noticing, but
> it's possible.)

> * Do it in userspace. Add functionality into the initramfs as
> necessary to wipe memory, and simply run an abbreviated shutdown.

> This lets us not have to deal with the potential for kexec's attack
> surface, and is probably some medium amount of code between the above
> two options. Downside is that it potentially is less reliable in
> terms of clearing memory than the other options, and is probably
> slower time-to-first-bit-erased than the other options.

> Does that seem like a fair summary to everyone?

It does seem like it to me.

> If so, which path seems the best for us to move forward on?

I prefer the two first options (mostly because the third one is
essentially what we're already doing, and are trying to
improve/replace).

Not sure which one of those two yet, but the next thing to do in both
cases is the same: make it possible to allow kexec without disabling
GRKERNSEC_KMEM entirely.

I don't know what configuration interface would be best: move kexec
disabling out of GRKERNSEC_KMEM, to another kernel build-time config
setting? Leave it as part of GRKERNSEC_KMEM, but add a sysctl to allow
re-enabling kexec at runtime? pipacs, spender: what do you think?

Cheers,
--
intrigeri