Hacker News Reader

Comment by vectorEQ | Hacker News Reader

all unikernels so far suck ALOT regarding security. wouldn't recommend any of them to run in any production environment unless you want to lose all of your data.

NCC group did a good article on unikernels and how crap they are if you want to know.

A better idea, like already suggested would be to create an OS which builds itself according to a target application and system, to host that application on said system specifically. that would reduce about as much code, but keep potential security mechanisms like aslr, stack protection , user / kernel separation etc. in tact. (now kernels / oses build to target system ,but not application! -> application would only use subset of kernel, and thus kernel can be built to target application, reducing kernel to whats needed).

don't try to be cheap for performance and skip security, we're not in the damned 80s anymore.

/endrant

View on HN

I'd argue the Mirage Unikernel (built almost wholly in OCaml) is one of the most robust platforms out there. The NCC paper you talk about looks at two rather old fashioned unikernels in isolation. I don't think the idea of unikernels should be discarded because the current implementations are slightly lacklustre -- it just shows that there's a fair way to go yet.

>[..] A better would be to host that application and reduce the kernel to whats needed

This is a unikernel.

The authors of the NCC paper are evaluating MirageOS as well. IIRC from listening to their talk on the paper and ongoing research https://www.youtube.com/watch?v=b68VFuB_y5M it's got more of the problems other unikernels do than I'd have assumed. I'm pretty ignorant, but the paper gave me the impression that there's a long (rather than fair) way to go yet, especially relative to seemingly widespread assumption that unikernels are inherently more secure.

If you read that article, they tested two unikernels and the key point was that unikernels don't implement security mechanisms present in a normal OS. This Linux Unikernel, otoh, does not delete any of that security functionality. The boot up code is the same, it just calls a specific code instead of bringing up the general userspace. Unikernels and security don't have to be mutually exclusive.

Genuinely curious: Wouldn't the teeny-tiny "attack surface" at least mitigate attacks, and should one be successful on say a memcache server running inside a unikernel... what exactly can you do on a "rooted" machine that has no userspace tooling or libraries? Assuming it's running in isolation, it wouldn't be much different than breaking into a container through an unprivileged process, right?

I was actually planning a Unikernel based deployment of Memcached (OSv) as a L2 cache for our application servers. I thought that user/kernel separation didn’t matter that much when only a single application is ran in a microkernel, and the data exfiltration risk would be the same as if we were running it on a typical Linux box.

Here are the mandatory links to the NCC whitepaper [0], and HN discussion [1]

[0] (large PDF) https://www.nccgroup.trust/globalassets/our-research/us/whit...

[1] https://news.ycombinator.com/item?id=20507283

We literally just talked about this in a video done yesterday for application security weekly - https://www.youtube.com/watch?v=Hob1iLjIgWE - I previously wrote my thoughts on it here as well:

https://nanovms.com/dev/tutorials/assessing-unikernel-securi...

Reply on news.ycombinator.com