Hacker News new | past | comments | ask | show | jobs | submit login
Assessing Unikernel Security [pdf] (nccgroup.trust)
53 points by liuw on April 24, 2019 | hide | past | favorite | 7 comments



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.


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.


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.


Only covers Rumprun and IncludeOS - not Unikernels in general


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


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


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.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: