3 ms·

Interesting, but I’m not convinced. Size: Each unikernel image contains a kernel specially compiled for the application. A container image properly optimized c

by ngrilly 11y ago

Interesting, but I’m not convinced. Size: Each unikernel image contains a kernel specially compiled for the application. A container image properly optimized contains just the application (the kernel is shared by all containers). It’s possible to create Docker containers under 10 MB: see http://blog.xebia.com/2014/07/04/create-the-smallest-possible-docker-container/ http://blog.xebia.com/2014/07/04/create-the-smallest-possibl... and http://blog.xebia.com/2015/06/30/how-to-create-the-smallest-possible-docker-container-of-any-image/ http://blog.xebia.com/2015/06/30/how-to-create-the-smallest-.... Security: Reusing a well known and largely deployed Linux kernel (without all the surrounding provided by the “larger” OS) sounds at least as secure as compiling its own specialized unikernel. Compatibility: The compatibility story sounds better for containers because your app will work by default without doing anything.

mlieberman85 11y ago
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.
- binarycrusader 11y ago
  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.
- tedunangst 11y ago
  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.
- steego 11y ago
  > 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.
  - Sanddancer 11y ago
    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.
- detrino 11y ago
  Can't you already achieve this with seccomp-bpf?
mtgx 11y ago
Apparently unikernel images can be as small as 200KB. http://blog.acolyer.org/2015/01/13/unikernels-library-operating-systems-for-the-cloud/ http://blog.acolyer.org/2015/01/13/unikernels-library-operat... That might be only for niche cases, though, but others seem to say it can be under 5MB for more general uses, too: http://www.techrepublic.com/article/unikernels-offer-a-stripped-down-alternative-to-linux/ http://www.techrepublic.com/article/unikernels-offer-a-strip... This is a nice talk on unikernels: https://www.youtube.com/watch?v=oHcHTFleNtg https://www.youtube.com/watch?v=oHcHTFleNtg
rjsw 11y ago
A unikernel can be pretty small, the sample one that comes with Xen builds to 230KB. Some of the OpenMirage builds are around 25MB.
jdc 11y ago
Regarding security, any distro install is going to have an attack surface several orders of magnitude higher than a unikernel. Does anyone know how the quantity of exploitable vulnerabilities varies with attack surface (ie. SLOC)?
pflanze 11y ago
The original poster says: "Given that unikernels compile only which is necessary into the applications, the surface area is very small." I think this is a somewhat strange statement. You don't lower the surface area by not compiling in dead code--unless you're offering a way to run arbitrary code, in which case it can help implementing the anti-features the attacker wants. But to me it seems the primary innovation of unikernels is that they are not implemented in C, but in a higher-level language like Ocaml, Erlang, etc. Those languages, if their compilers and runtimes are implemented correctly, don't allow buffer overflows, and have also other features to prevent arbitrary code execution (type system, or secure process isolation). Those kernels have (given the same attention to quality) the potential of being more secure than the Linux kernel by using such languages. Also, by not having to be a general OS kernel, they are simpler to implement, hence reducing the number of bugs likely to be around. It's not the "compiling into the application", it's the "implementation of the algorithms" that's smaller. Perhaps that's what the original poster meant, but it sounded strange to me.
deleted 11y ago
[deleted]
axelfontaine 11y ago
At Boxfuse (https://boxfuse.com https://boxfuse.com) we decided to combine the best of both worlds: dynamically generated minimal Linux-based images. They are just a few MBs in size, generated in seconds and start almost instantly, yet retain the tried and true quality and compatibility of the Linux kernel. We coupled that with a secure repository and blue/green AWS deployments for a great out of the box experience.

by ngrilly 11y ago

mlieberman85 11y ago

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.

binarycrusader 11y ago
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.
tedunangst 11y ago
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.
steego 11y ago
> 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.
- Sanddancer 11y ago
  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.
detrino 11y ago
Can't you already achieve this with seccomp-bpf?

mtgx 11y ago

Apparently unikernel images can be as small as 200KB. http://blog.acolyer.org/2015/01/13/unikernels-library-operating-systems-for-the-cloud/ http://blog.acolyer.org/2015/01/13/unikernels-library-operat... That might be only for niche cases, though, but others seem to say it can be under 5MB for more general uses, too: http://www.techrepublic.com/article/unikernels-offer-a-stripped-down-alternative-to-linux/ http://www.techrepublic.com/article/unikernels-offer-a-strip... This is a nice talk on unikernels: https://www.youtube.com/watch?v=oHcHTFleNtg https://www.youtube.com/watch?v=oHcHTFleNtg

rjsw 11y ago

A unikernel can be pretty small, the sample one that comes with Xen builds to 230KB. Some of the OpenMirage builds are around 25MB.

jdc 11y ago

Regarding security, any distro install is going to have an attack surface several orders of magnitude higher than a unikernel. Does anyone know how the quantity of exploitable vulnerabilities varies with attack surface (ie. SLOC)?

pflanze 11y ago

The original poster says: "Given that unikernels compile only which is necessary into the applications, the surface area is very small." I think this is a somewhat strange statement. You don't lower the surface area by not compiling in dead code--unless you're offering a way to run arbitrary code, in which case it can help implementing the anti-features the attacker wants. But to me it seems the primary innovation of unikernels is that they are not implemented in C, but in a higher-level language like Ocaml, Erlang, etc. Those languages, if their compilers and runtimes are implemented correctly, don't allow buffer overflows, and have also other features to prevent arbitrary code execution (type system, or secure process isolation). Those kernels have (given the same attention to quality) the potential of being more secure than the Linux kernel by using such languages. Also, by not having to be a general OS kernel, they are simpler to implement, hence reducing the number of bugs likely to be around. It's not the "compiling into the application", it's the "implementation of the algorithms" that's smaller. Perhaps that's what the original poster meant, but it sounded strange to me.

deleted 11y ago

[deleted]

axelfontaine 11y ago

At Boxfuse (https://boxfuse.com https://boxfuse.com) we decided to combine the best of both worlds: dynamically generated minimal Linux-based images. They are just a few MBs in size, generated in seconds and start almost instantly, yet retain the tried and true quality and compatibility of the Linux kernel. We coupled that with a secure repository and blue/green AWS deployments for a great out of the box experience.