111–120 of 142 posts
>"Unikernels on the other hand don’t have system calls. They only have function calls."
If my program is compiled against glibc functions which wrap actual system calls how does my program work when there is no userland?
Is there a compiler that compiles my program to a unikernel target? Can someone explain how this works?
But the whole point of userspace is to provide privilege separation between the kernel and userspace. In unikernels everything is in the kernel, and you can freely mutate in-kernel state without any segmentation violations. In other words, of course there are no syscalls when there is no separation between user code and the kernel ("no syscalls" is the description of a unikernel). So, what is the tangible security benefit?
What I want to know is how do you protect against in-kernel ROP? Or hell, just plain old-fashioned stack overflows? The ASLR mentioned is not really useful because it's only on-recompile (Linux's ASLR is on-execution). The only experience I've had with writing shell code was messing around with https://microcorruption.com/ for a few evenings, and even I know that putting everything into the same address space is just asking for trouble (of course you can mitigate it, but praising the premise as a feat of security seems to be missing the point to me).
Maybe I'm just massively misinformed, but I simply don't see how someone can proclaim that "unikernels are secure" by just re-stating the premise as the justification for their security (and then following up with a bunch of hypotheticals).
> Good luck guessing that address. Our own unikernel, IncludeOS, randomizes addresses at each build, so even with access to source code you still don’t know the memory layout. "There is one mortal sin in computer security (or by the way, in any kind of security) that is feeling safe. It’s just a variation of pride to be true, but it’s very deadly. Blindly trusting a protection technology is an extreme error." Read up…
is linux randomizing is per exec ? ps: BSD have started to randomize at boot time, fun times
BSD also does the same for userspace, but their new feature is that they randomise the kernel per-boot (by re-linking the objects). This is a far stronger form of kASLR (though I think they're calling it something else because it requires relinking the kernel binary).
Even Windows does this well.
Bragging about boot-time ASLR seems quite odd for an article like this, given that traditional operating systems have had similar (and in many ways superior) features like this for more than a decade (PaX introduced ASLR in Linux in 2001, OpenBSD had it by-default in 2003, and Linux shipped it by-default in 2005).
Earlier quoted context omitted.
No, that's like saying that we don't know what shape the world is before we could prove that it is round.
No, it's like saying it is round "if and only if" we can prove that it is round.
Earlier quoted context omitted.
Why are millisecond bit times necessary? Linux doesn't boot in a millisecond...
Because you can then build single function unikernels that do one thing very fast then disappear from RAM. The point being that docker is actually a really clunky thing that is reinventing the virtual server ecosystem within the OS which is pointless. Serverless systems are better implemented as unikernels than docker images. Unikernels make it possible to boot an entire OS in milliseconds, service an inbound web req…
I would hesitate to call something Secure unless some major pen test effort were engaged to try to break it. This is a corollary to "If it isn't tested it is broken". (Another corollary is "Even if it is tested, it may still be broken.") This is more so with security. Just looking at some of the assumptions, e.g., that the lack of a shell significantly increases the difficulty of an attack, leaves me with doubts abou…
Precisely. On another domain: "My crypto algorithm has never been broken, it is secure". No it is not, it's just too irrelevant for anyone to be interested in auditing it.
> Unikernels have no shells. Most attacks I’ve seen invoke /bin/sh to modify the system they are attacking. Without a shell the attacker doesn’t have this opportunity. This forces the attacker to use machine code to subvert the system, decreasing the likelihood of succeeding with the attack. This argument is completely incoherent.
And, while this is a more minor rebuttal, it's still worth saying: it's totally incorrect . Modern exploits (for definitions of "modern" meaning "written after 1999") do not care if you have a shell on your system. The author has presumably confused the concept of a POC, which is an exploit reduced and simplified for the consumption and understanding of laypeople, with that of a real exploit.
A unikernel application which only executes native code[2], combined with a hypervisor / hardware that enforces immutable page tables and NX, AFAICT leaves ROP/JOP as the sole remaining attack vector for RCE. Further, each deployment of the application should be done via a new build (or at least re-link), which can employ the build-time ASLR Per mentions to mitigate ROP/JOP attacks.
I'd be interested in your thoughts on what other relevant attack vectors I've not thought of that would allow for a persistent compromise of a unikernel. Feel free to discuss here or on the devel.unikernel.org forum thread[3].
[1] Page 4 in this whitepaper from 2015: https://wiki.xenproject.org/images/3/34/XenProject_Unikernel...
[2] Does not contain a JIT or interpreter able to "eval()" new code.
[3] https://devel.unikernel.org/t/unikernels-are-secure-here-is-...
Earlier quoted context omitted.
Excellent discussion. I'm not knowledgeable enough in Linux internals to know whether the ring0 versus ring3 criticism is warranted. Is it just a matter of if/when an attacker achieves escalated privileges they will have far more attack surface on ring0?
There is quite a difference. Ring 3 is userspace, you can't interact with hardware or the operating system or anything not in Ring 3 directly. Ring 0 is everything. There are no restrictions and nothing stops you from writing "Ahahah You didn't say the magic word!" over your entire memory until the CPU crashes. Having root on a linux kernel is heavily restricted compared to this and still runs in Ring 3 like all othe…
In the case of a unikernel deployed on a hypervisor this is not the case, since there is not much else in ring 0 that you wouldn't already have access to from ring 3. Conceptually you can think of the hypervisor as "kernel space" and anything inside the unikernel as "userspace".
There are advantages to running the unikernel solely in ring 3 (eg. immutable page tables) however this is not a requirement for security.
Earlier quoted context omitted.
There is quite a difference. Ring 3 is userspace, you can't interact with hardware or the operating system or anything not in Ring 3 directly. Ring 0 is everything. There are no restrictions and nothing stops you from writing "Ahahah You didn't say the magic word!" over your entire memory until the CPU crashes. Having root on a linux kernel is heavily restricted compared to this and still runs in Ring 3 like all othe…
Access to ring 0 on a traditional OS is indeed usually "game over". In the case of a unikernel deployed on a hypervisor this is not the case, since there is not much else in ring 0 that you wouldn't already have access to from ring 3. Conceptually you can think of the hypervisor as "kernel space" and anything inside the unikernel as "userspace". There are advantages to running the unikernel solely in ring 3 (eg. immu…
When Ring 0 is compromised, there is no alert or anything to protect the app from compromise. If there is an exploit, it's game over.
However, in Ring 3 and a normal kernel, you get various protections that allow the kernel to recognize some attacks and shutdown the application immediately or even shutdown the kernel.
This prevents a compromised app from running to some extend.
A unikernel cannot do this. If the app is compromised and I don't notice and don't restart it...
Even worse, the attacker could use it as leverage to infect other unikernel based instances of the app to gain some permanence against restarts by simply reinfecting when an instance goes down.
The unikernel is not userspace, not even conceptually. The hpyervisor will not shutdown the app unless it executes illegal instructions. The kernel will shutdown misbehaving programs more easily.