[Cryptography] WIPEONFORK in Linux 4.14

[Tom Mitchell]

On Mon, Nov 27, 2017 at 11:54 PM, Darren Moffat <darren at nessieroo.com>
wrote:

> Is the use case for when we are purposely creating a multi-process system,
> by using fork/vfork/clone,
>

Fork also duplicates a number of things not just data (copy on write)
but also file descriptors, UID, GUD, effective  UID and GID, atributes for
SeLinux and more state.
A privileged process needs to reliably shed some data and privledge to not
leak information.

A single binary can contain code to do a multitude of things. Some  that
should not happen in the same binary or process.
A named pipe or shared memory buffer could be used by a generator in a
forked-child to feed
data to the parent or yet another process.  I.e. a child might interact
with dev/random and a PRNG but keep the random seed hidden from the parent.
  Each child would wake to find a clean slate
and not see any 'secrets' that were marked to be wiped but could cooperate
in a multi process problem.

Example to ponder:  BusyBox: The Swiss Army Knife of Embedded Linux does a
lot of stuff
in one binary and one acts like a shell.   Any of its child processes could
be a fork()
or fork(); exec() pair of itself with another entry point. Commonly built
and fully linked to not depend on shared objects there are lots of eggs
(tools) in one basket.

Wipe on fork seems necessary but may not solve all problems.  In crypto a
Swiss Army knife binary an advantage could be a single file atomic update
that is “easy to update” but would contain tools to operate, on keys,
input, output, generate keys, etc...  perhaps too many things.

SSD files that are ephemeral could be unlinked and encrypted with a one
time dev/random pad generated and optionally expanded perhaps with a PRNG
so any part of the pad can be regenerated using a use once true random seed
set and XOR to obscure bits on SSD components or even hidden blocks on
spinning rust should there be a power interruption or core dump.

Persistent data and encryption is a hard, key management problem especially
in a multiuser system.

-- 
  T o m    M i t c h e l l
-- 
Tinny keyboard.. Mobile ... I am
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20171129/6dc545c2/attachment.html>