
Assessing Unikernel Security [pdf] - liuw
https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2019/ncc_group-assessing_unikernel_security.pdf
======
tptacek
This paper is pretty excellent. In particular I sort of love that they
included a "Hypothesis" section that laid out what their expectations about
security were.

They set out to confirm a hunch that despite reducing attack surface by using
stripped-down kernels, unikernel applications would be less secure than
containerized applications because the unikernels would have relatively
primitive runtime security, compared to Linux container systems which inherit
two decades of countermeasure work.

They tested IncludeOS and Rumprun and found both to have approximately
1998-levels of runtime hardening. IncludeOS in particular was a steaming
crater at the end; a stack overflow on IncludeOS could write directly into the
(writeable!) program text, and the NULL page was writeable and executable.

~~~
saagarjha
Notably, the author of the paper seems to state that the implementers of the
unikernels either didn't really understand how to implement proper security
features or purposely weakened or disabled protections that would have been
enabled by default.

~~~
fwsgonzo
Really is too bad they started auditing IncludeOS when it was so early in
development that there wasn't even paging. It was just a pagetable to enter
64-bit then.

Today it lacks ASLR, and the network stack needs auditing.

------
jdc
Only covers Rumprun and IncludeOS - not Unikernels in general

~~~
Ericson2314
yeah "stripped down" monolithic kernels rather than "built up" libraries are
basically guaranteed to not be much better architecturally.

------
tilt_error
I assume Nabla and Solo5 would be scoring great in this (type of) test?

~~~
mato
I can't comment on the Nabla parts as I don't work on that and have not read
the code in any detail, but upstream Solo5 (and thus MirageOS on Solo5) has
gradually been getting fixes for most of the "security posture" issues
identified by NCC in this paper over the last few months. Note that not all of
these issues apply to Solo5 in the first place.

The notable thing missing at the moment is ASLR and a more robust guest memory
layout in general. We have an issue with a plan for that but it's a matter of
balancing a finite amount of time/manpower and priorities.

