Hacker News Reader

Comment by mlieberman85 | Hacker News Reader

As far as security is concerned a unikernel with lower attack surface will beat out a general kernel. A unikernel for AppX will have a completely different attack surface from AppY so most generalized attacks just won't work. Shell attacks like heartbleed won't work because there is no shell. Given that there's a single process, even if you did compromise the system there's not a whole lot you can do with it.

View on HN

> A unikernel for AppX will have a completely different attack surface from AppY so most generalized attacks just won't work.

If unikernal systems do become popular, it's very likely this would not be true because AppX and AppY would likely share a popular library that they've both been statically linked against. (Ex: An HTTP library with TLS). Granted, the footprint of exploitable features would be considerably smaller

I agree more with the the latter point that a compromised system would probably offer very little for an attacker to leverage.

I imagine that a unikernel management system would have all the modules -- http, tls, the user facing app, etc -- just as object files, so that an update of the TLS library would entail little more than relinking and restarting the new unikernels.

I think you mean shellshock, but people were only vulnerable to shellshock if they were actually using bash for something. And anybody using bash is, by necessity, going to include it in their virtualunicontainerimage.

I think the poster's point is that a unikernel may have an overall lower attack surface, but it now has a different, unique attack surface.

That seems like it might be a legitimate concern.

There's also support considerations to taken into account as well from a vendor perspective.

Can't you already achieve this with seccomp-bpf?

Reply on news.ycombinator.com