Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Assessing Unikernel Security [pdf]

nccgroup.trust

Post reply on HN
Print view View original

1–9 of 9 posts

Re: Assessing Unikernel Security [pdf]

#4

Post by 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.

Re: Assessing Unikernel Security [pdf]

#6

Post by saagarjha »

tptacek wrote: post #4

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…

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.

Re: Assessing Unikernel Security [pdf]

#7

Post by fwsgonzo »

saagarjha wrote: post #6
tptacek wrote: post #4

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…

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.

Re: Assessing Unikernel Security [pdf]

#8

Post by mato »

tilt_error wrote: post #5

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.

Post reply on HN