Hi Sebastien and Philip,
Thanks for your clarifications. It was interesting to learn to know that
you should have a swap drive on the "root disk" (that is on the crypto
softraid) for catching kernel panic coredumps to.
I guess my last question on this topic of kernel panic coredump on swap
drive, would be:
How large should the swap drive be to accomodate any such coredump - the
same size as the physical RAM of the machine, or less, or more?
(Unimportant followup questions to Philip below.)
Thanks,
Tinker
On 2017-02-04 01:10, Sebastien Marie wrote:
[..]
Just comments based on my understanding of swap and crypto softraid
interaction (so I could be wrong).
Considering the swap on crypto softraid for swap usage, yes it means
double encryption, and so it is a bit inefficient.
Aha.
Considering the swap to hold bsd.core information, having a layer of
encryption is necessary for my point of vue (so using the swap on
crypto
softraid).
My understanding is if savecore(8) is able to extract bsd.core
information from swap partition, it means the bsd.core information is
*not* encrypted by crypto-swap (else, as keys are discarded on reboot,
savecore(8) wouldn't have any way to uncrypt the swap without keys). So
as bsd.core is readable by savecore(8), it means it is also readable by
attacker (by direct read of the swap partition - unplug the disk and
voila).
Ahh, that is an excellent point.
Now, if the swap partition is on crypto-softraid, before accessing the
swap layer, an attacker needs the key of crypto-softraid. So bsd.core
information is protected from above attack.
Right.
On my laptop (with full disk encryption), I use two swap partitions:
- one on sd0b (for "normal" swap purpose)
- one on sd1b (for holding bsd.core information in case of panic)
And I adjust the priority of sd1b to make sd0b used first (in
rc.local):
swapctl -c -p 1 /dev/sd1b
On panic, it is always sd1b which is used (as my root disk is sd1a) for
holding bsd.core information.
Comments are welcome.
On 2017-02-04 03:17, Philip Guenther wrote:
On Fri, 3 Feb 2017, Sebastien Marie wrote:
...
My understanding is if savecore(8) is able to extract bsd.core
information from swap partition, it means the bsd.core information is
*not* encrypted by crypto-swap (else, as keys are discarded on reboot,
savecore(8) wouldn't have any way to uncrypt the swap without keys).
So
as bsd.core is readable by savecore(8), it means it is also readable
by
attacker (by direct read of the swap partition - unplug the disk and
voila).
Right: if your system crashes and is made to write do "boot crash" then
the information that was in memory at the time will be written out
without
being affected by whether swap encryption is enabled. That's not what
swap encryption is for.
So that's what happens when you have "reboot on panic" (sysctl
ddb.panic=0) set, and you get a kernel panic.
If someone can get to ddb they can peel all the information out the
kernel anyway!
Sure.
I guess you not had a particular point here. I think generally it's
easier to steal a harddrive, than to steal access to someone's kernel
debugger (in default OpenBSD configuration [where ddb.panic=1], the only
way to get into the kernel debugger would be if the robber succeeded
with keeping the device powered on, and, somehow induce a kernel panic).
Swap encryption is like selecting a TLS cipher suite that uses an
ephemeral key to get forward security: the goal is to make it so that
when
you choose to forget the past, it really is gone and can't be dredged
up.
Let's imagine that FDE on your box is defeated or evaded:
- laptop is stolen while you're logged in
- government locks you up until you decrypt
- criminals use 'rubber-hose cryptanalysis'
- actual crypto failure
At that point, they have all your *current* data. What do they see if
they then look at your swap partition? If you didn't use swap
encryption
then they see data from the possibly-distant past; if you used swap
encryption then they would only see what the currently running system
could see and *not* anything beyond the immediate past.
Did you have a point here? I don't see how this relates with whether the
swap has one or two layers of crypto atop it -
If only one (ordinary swap encryption), then after reboot all old swap
is likely lost - but a kernel panic coredump on the swap would be
unencrypted and stay around on the disk for quite a while.
If double (ordinary swap encryption + crypto softraid), then after
reboot all old swap is likely lost, and retrieval of panic coredump data
(new or any old) from the crypto softraid-based swap would require the
softraid's crypto key.
Now, if the swap partition is on crypto-softraid, before accessing the
swap layer, an attacker needs the key of crypto-softraid. So bsd.core
information is protected from above attack.
Correct, though in that case the attacks above will then also be able
to
see what was on your machine at that past time. Someone paranoid about
what's in memory on their box and for whom the attacks above are a
concern
should disable entry into ddb (ddb.panic=0 and ddb.console=0) and never
write out crash dumps.
Right.
