[prev in list] [next in list] [prev in thread] [next in thread]
List: cryptography
Subject: Re: [Cryptography] WIPEONFORK in Linux 4.14
From: Tom Mitchell <mitch () niftyegg ! com>
Date: 2017-11-29 7:07:42
Message-ID: CAAMy4UQ2V0e-KMEwprTWs6SEF0s-MxPhU+yTvzYUHDOvymZbVw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Mon, Nov 27, 2017 at 11:54 PM, Darren Moffat <darren@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
[Attachment #5 (text/html)]
<div><div><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 27, 2017 at \
11:54 PM, Darren Moffat <span><<a href="mailto:darren@nessieroo.com" \
target="_blank">darren@nessieroo.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="auto">Is the use case for when we are \
purposely creating a multi-process system, by using fork/vfork/clone, \
</div></blockquote><div> </div></div></div></div></div><div><div class="gmail_extra" \
dir="auto"><div class="gmail_quote"><div>Fork also duplicates a number of things not \
just data (copy on write)<br></div><div>but also file descriptors, UID, GUD, \
effective UID and GID, atributes for SeLinux and more state. </div><div \
dir="auto">A privileged process needs to reliably shed some data and privledge to not \
leak information. </div><div dir="auto"><br>A single binary can contain code to do a \
multitude of things. Some that should not happen in the same binary or process. \
</div><div>A named pipe or shared memory buffer could be used by a generator in a \
forked-child to feed </div><div>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</div><div>and not see any \
'secrets' that were marked to be wiped but could cooperate in a multi process \
problem. </div><div dir="auto"><br>Example to ponder: BusyBox: The Swiss Army \
Knife of Embedded Linux does a lot of stuff</div><div>in one binary and one acts like \
a shell. Any of its child processes could be a fork()</div><div>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.</div><div \
dir="auto"><br></div><div dir="auto">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. </div><div \
dir="auto"><br></div><div dir="auto">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. </div><div \
dir="auto"><br></div><div dir="auto">Persistent data and encryption is a hard, key \
management problem especially in a multiuser \
system.</div></div></div></div><div><div><div class="gmail_extra"><div><br></div>-- \
<br><div class="m_1352826366580992441gmail_signature"><div> T o m M i t c h e \
l l</div></div> </div></div></div><div dir="ltr">-- <br></div><div \
class="gmail_signature" data-smartmail="gmail_signature">Tinny keyboard.. Mobile ... \
I am</div>
[Attachment #6 (text/plain)]
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic