Not really. Now instead of having to break the application, then break the kernel it's running under and then attack the VM host, you only have to attack the app and can then go directly at the VM host.
Unikernels just remove a whole security layer. May as well run the app as a user process on the host and forget the VM.
It depends on what you're securing and what the weakest link in your chain is. The assumption is that your app is doing something valuable (i.e. there is value in compromising the app, not just as a means of compromising the host).
Perhaps I should have phrased that differently, but you've reduced the attack surface for compromising your _app_ via the environment (instead of the environment via your app).
(big disclaimer: this is assuming Xen bugs are much more valuable than app bugs and someone with a Xen exploit won't be focusing on you.)
unikernels do not have to run in ring 0 although a lot of early ones did. You can run them in ring 2, and they probably never need ring 0 access after boot so there does not have to be any way to return.
Wrong. Cracking the app does not give you access to the VM host. These apps are running in a VM. There's no relationship at all between cracking the app and cracking VM host.
I believe what zlynx meant was that if you want to escalate from the VM to the host, you usually do that via the virtualised devices. On a normal system, your path (for a web service on Linux) would be:
App exploit (-> LSM breakout?) -> local to root escalation -> VM to host escalation via device.
Maybe I'm mistaken but it seems to me that the parent's argument was that running your app in a unikernal prevents another app from crapping all over it, ie: root escalation happened in an adjacent app and now your app is at risk.
It does move the hypervisor up a few levels of abstraction, which could be dangerous, but (more to the point) the benefit is isolation from other misbehaving apps.
