Anyone with first-hand experience of unikernels in production? From a distance it looks good but I have reservations regarding observability but that might just be due to a lack of knowledge on my part. Is it possible run something akin to "perf record" on a unikernel application/system?
An honest question I don't know how to phrase without sounding hubristic:
I haven't used a unikernel in production, but I have experimented with them casually. I haven't found a use case yet where the benefits outweight the downsides. I don't care about POSIX interfaces, but if I'm going to write a program that writes to a buffer on my computer in some roundabout way anyway, why is pretending I'm writing to a serial port any better? It still goes through a scheduler, a buffer at one priviledge level (VM), a buffer at another priviledge level (hypervisor), to maybe a NIC or other IO device.
The security benefits don't make a ton of sense to me either. It doesn't seem like it meaningfully changes the things a malicious actor would want to do remotely, but mostly how you do them. If I wanted to steal a secret, I just wouldn't do it by spawning a shell.
I know there are real benefits -- start time, security by reduction, compartive overhead with respect to the usual kernel->vm->virtual userspace->application stack, but in what use case does that actually mean enough to be the practically better option?
I can't speak for all projects but the focus on a single process system (eg: can't have a shell since it is inherently built to run many different programs) - that's a huge limiting factor for doing anything remotely interesting from an attacker's point of view. Most people trying to break into a server could care less about the vulnerability in your application or the sploit they are using - they want to run their programs on your server.
For instance if you want to install a cryptominer via the recent php2shell issue - chances are that's not going to be ran in php and while you could conceivably ROP your way to success here that's not reality. Same thing if you wanted to add it to a botnet. A botnet lord wont use it cause their dropper is meant to run many different payloads (whatever payload someone paid them to drop).
Really, if you look at any of the recent npm/github/etc. malware or any ransomware/cryptominer campaigns or any of it - it is largely dependent upon the actor wanting to run other software.
For me the the 'attack surface reduction' is commonly gets cited is the least interesting security aspect of these things.
That makes sense malware-economically. It's not "it's harder to do a bad thing in general," it's "this is a less capable target, and takes a lot more effort to exploit by obscurity."
I do still wonder, what's stopping me from attacking your unikernel by figuring out how to write to your page table, removing an NX, and ROPing my way into executing my code on your machine? If my intuition is right, then a vulnerable target doesn't become less vulnerable because you switch to a unikernel, it just becomes less valuable iff the thing I want to do isn't specific enough.
There are indeed projects out there that let you modify page perms quite easily - nanos (the one i'm involved with), like linux, respects them so you'd need to find a write/exec primitive first. As for ROP - most exploits that do that eventually intend to run their own program, either by exec'ing a new process or hollowing our the existing space, not code the entire program in ROP. For instance, I've yet to see a mysqldump or miner written in pure gadgets.
rbjoerklin | 4 hours ago
Anyone with first-hand experience of unikernels in production? From a distance it looks good but I have reservations regarding observability but that might just be due to a lack of knowledge on my part. Is it possible run something akin to "perf record" on a unikernel application/system?
interlandi | 3 hours ago
An honest question I don't know how to phrase without sounding hubristic:
I haven't used a unikernel in production, but I have experimented with them casually. I haven't found a use case yet where the benefits outweight the downsides. I don't care about POSIX interfaces, but if I'm going to write a program that writes to a buffer on my computer in some roundabout way anyway, why is pretending I'm writing to a serial port any better? It still goes through a scheduler, a buffer at one priviledge level (VM), a buffer at another priviledge level (hypervisor), to maybe a NIC or other IO device.
The security benefits don't make a ton of sense to me either. It doesn't seem like it meaningfully changes the things a malicious actor would want to do remotely, but mostly how you do them. If I wanted to steal a secret, I just wouldn't do it by spawning a shell.
I know there are real benefits -- start time, security by reduction, compartive overhead with respect to the usual kernel->vm->virtual userspace->application stack, but in what use case does that actually mean enough to be the practically better option?
eyberg | 3 hours ago
I can't speak for all projects but the focus on a single process system (eg: can't have a shell since it is inherently built to run many different programs) - that's a huge limiting factor for doing anything remotely interesting from an attacker's point of view. Most people trying to break into a server could care less about the vulnerability in your application or the sploit they are using - they want to run their programs on your server.
For instance if you want to install a cryptominer via the recent php2shell issue - chances are that's not going to be ran in php and while you could conceivably ROP your way to success here that's not reality. Same thing if you wanted to add it to a botnet. A botnet lord wont use it cause their dropper is meant to run many different payloads (whatever payload someone paid them to drop).
Really, if you look at any of the recent npm/github/etc. malware or any ransomware/cryptominer campaigns or any of it - it is largely dependent upon the actor wanting to run other software.
For me the the 'attack surface reduction' is commonly gets cited is the least interesting security aspect of these things.
interlandi | 3 hours ago
That makes sense malware-economically. It's not "it's harder to do a bad thing in general," it's "this is a less capable target, and takes a lot more effort to exploit by obscurity."
I do still wonder, what's stopping me from attacking your unikernel by figuring out how to write to your page table, removing an NX, and ROPing my way into executing my code on your machine? If my intuition is right, then a vulnerable target doesn't become less vulnerable because you switch to a unikernel, it just becomes less valuable iff the thing I want to do isn't specific enough.
eyberg | 2 hours ago
There are indeed projects out there that let you modify page perms quite easily - nanos (the one i'm involved with), like linux, respects them so you'd need to find a write/exec primitive first. As for ROP - most exploits that do that eventually intend to run their own program, either by exec'ing a new process or hollowing our the existing space, not code the entire program in ROP. For instance, I've yet to see a mysqldump or miner written in pure gadgets.