thread moved from misc@ to tech@ due to a diff.
(see http://marc.info/?l=openbsd-bugs&m=148612339714423 for previous
messages)
On Sat, Feb 04, 2017 at 09:47:04PM +0800, Tinker wrote:
> 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?
I think it is at least the physical RAM of the machine.
crash(8) man page stands for:
When the system crashes it writes (or at least attempts to write) an
image of memory, including the kernel image, onto the dump device.
So physical RAM + some megas for kernel ?
> 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.
on panic, the system will not enter in ddb(4). Only a stack trace will
be print on console.
next, reboot(2) is called with RB_AUTOBOOT | RB_DUMP.
RB_AUTOBOOT The default, causing the system to reboot in its usual
fashion.
RB_DUMP Dump kernel memory before rebooting; see savecore(8) for
more information.
so a crash dump (bsd.core) is written to dump device.
> > 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.
the swap-crypto layer is useful when the system is used in normal
operation (no panic). it ensures between two boots the swap device
contains only data from current boot.
I agree that panic() introduce a way to put potential sensitive data
unencrypted on dump device (the swap partition).
The device could be encrypted with crypto-softraid or not.
> > > 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.
>
Reading panic() code (inside sys/kern/subr_prf.c), it seems that on
panic(9), crash dumps are written as soon as dumpdev is available.
Does a sysctl to ask kernel to not call dumpsys() on panic(9) would be
useful ?
--
Sebastien Marie
Index: lib/libc/gen/sysctl.3
===================================================================
RCS file: /cvs/src/lib/libc/gen/sysctl.3,v
retrieving revision 1.273
diff -u -p -r1.273 sysctl.3
--- lib/libc/gen/sysctl.3 7 Oct 2016 20:58:12 -0000 1.273
+++ lib/libc/gen/sysctl.3 4 Feb 2017 16:37:16 -0000
@@ -421,6 +421,7 @@ information.
.It Dv KERN_CPTIME2 Ta "u_int64_t[CPUSTATES]" Ta "no"
.It Dv KERN_DNSJACKPORT Ta "integer" Ta "yes"
.It Dv KERN_DOMAINNAME Ta "string" Ta "yes"
+.It Dv KERN_DUMPONPANIC Ta "integer" Ta "yes"
.It Dv KERN_FILE Ta "struct kinfo_file" Ta "no"
.It Dv KERN_FORKSTAT Ta "struct forkstat" Ta "no"
.It Dv KERN_FSCALE Ta "integer" Ta "no"
@@ -531,6 +532,13 @@ When non-zero, the localhost port to whi
redirected.
.It Dv KERN_DOMAINNAME
Get or set the YP domain name.
+.It Dv KERN_DUMPONPANIC
+When this variable is set, system panics may dump kernel memory before
+rebooting.
+When running with a
+.Xr securelevel 7
+greater than 0,
+this variable may not be raised.
.It Dv KERN_FILE
Return the entire file table, or a subset of it.
An array of
Index: sbin/sysctl/sysctl.8
===================================================================
RCS file: /cvs/src/sbin/sysctl/sysctl.8,v
retrieving revision 1.208
diff -u -p -r1.208 sysctl.8
--- sbin/sysctl/sysctl.8 15 Oct 2016 14:43:53 -0000 1.208
+++ sbin/sysctl/sysctl.8 4 Feb 2017 16:37:16 -0000
@@ -194,6 +194,7 @@ and a few require a kernel compiled with
.It kern.wxabort Ta integer Ta yes
.It kern.consdev Ta string Ta no
.It kern.global_ptrace Ta integer Ta yes
+.It kern.dump_on_panic Ta integer Ta yes
.It vm.vmmeter Ta struct Ta no
.It vm.loadavg Ta struct Ta no
.It vm.psstrings Ta struct Ta no
Index: sys/kern/kern_sysctl.c
===================================================================
RCS file: /cvs/src/sys/kern/kern_sysctl.c,v
retrieving revision 1.321
diff -u -p -r1.321 kern_sysctl.c
--- sys/kern/kern_sysctl.c 21 Jan 2017 05:42:03 -0000 1.321
+++ sys/kern/kern_sysctl.c 4 Feb 2017 16:37:17 -0000
@@ -632,6 +632,22 @@ kern_sysctl(int *name, u_int namelen, vo
dnsjackport = port;
return 0;
}
+ case KERN_DUMPONPANIC: {
+ extern int dump_on_panic;
+ if (securelevel > 0)
+ return sysctl_int_lower(oldp, oldlenp, newp, newlen,
+ &dump_on_panic);
+ else {
+ int ctlval = dump_on_panic;
+ if ((error = sysctl_int(oldp, oldlenp, newp, newlen,
+ &ctlval)) || newp == NULL)
+ return error;
+ if (ctlval != 1 && ctlval != 0)
+ return EINVAL;
+ dump_on_panic = ctlval;
+ return 0;
+ }
+ }
default:
return (EOPNOTSUPP);
}
Index: sys/kern/subr_prf.c
===================================================================
RCS file: /cvs/src/sys/kern/subr_prf.c,v
retrieving revision 1.87
diff -u -p -r1.87 subr_prf.c
--- sys/kern/subr_prf.c 17 May 2016 23:43:47 -0000 1.87
+++ sys/kern/subr_prf.c 4 Feb 2017 16:37:17 -0000
@@ -128,6 +128,11 @@ int db_is_active;
#endif
/*
+ * use RB_DUMP on panic ?
+ */
+int dump_on_panic = 1;
+
+/*
* panic on spl assertion failure?
*/
int splassert_ctl = 1;
@@ -185,7 +190,10 @@ panic(const char *fmt, ...)
/* do not trigger assertions, we know that we are inconsistent */
splassert_ctl = 0;
- bootopt = RB_AUTOBOOT | RB_DUMP;
+ bootopt = RB_AUTOBOOT;
+ if (dump_on_panic)
+ bootopt |= RB_DUMP;
+
va_start(ap, fmt);
if (panicstr)
bootopt |= RB_NOSYNC;
Index: sys/sys/sysctl.h
===================================================================
RCS file: /cvs/src/sys/sys/sysctl.h,v
retrieving revision 1.171
diff -u -p -r1.171 sysctl.h
--- sys/sys/sysctl.h 21 Jan 2017 05:42:03 -0000 1.171
+++ sys/sys/sysctl.h 4 Feb 2017 16:37:18 -0000
@@ -184,7 +184,8 @@ struct ctlname {
#define KERN_GLOBAL_PTRACE 81 /* allow ptrace globally */
#define KERN_CONSBUFSIZE 82 /* int: console message buffer
size */
#define KERN_CONSBUF 83 /* console message buffer */
-#define KERN_MAXID 84 /* number of valid kern ids */
+#define KERN_DUMPONPANIC 84 /* int: dumpsys() on panic() */
+#define KERN_MAXID 85 /* number of valid kern ids */
#define CTL_KERN_NAMES { \
{ 0, 0 }, \
@@ -269,6 +270,9 @@ struct ctlname {
{ "proc_nobroadcastkill", CTLTYPE_NODE }, \
{ "proc_vmmap", CTLTYPE_NODE }, \
{ "global_ptrace", CTLTYPE_INT }, \
+ { "gap", 0 }, \
+ { "gap", 0 }, \
+ { "dump_on_panic", CTLTYPE_INT }, \
}
/*
