81–90 of 142 posts
Earlier quoted context omitted.
Without a formal proof there is no measure of correctness at all.
Lots of passing tests mean nothing to you?
It's secure if and only if there's a formal proof.
Earlier quoted context omitted.
Keep in mind that it's ring 0 inside a VM that contains almost nothing. Really a unikernel is just a process that uses hypercalls instead of system calls. So exploiting a unikernel is no worse than exploiting a user process, and the article explains a few reasons it could be more secure. But they should definitely add ASLR.
Just like an operating-system executes processes, a VMM executes unikernels. An operating system is responsible for randomizing the layout of processes in memory. Shouldn't the actual question here be "Does my hypervisor implement some mechanism for randomizing the layout of my unikernel?"
I don't really like the argument that something is 'secure' because it is not vulnerable in the same ways that an alternative is. I think this is why I like talking about encryption so much. It's possible to mathematically prove the security of encryption algorithms, and all that's really left to pick apart is the implementation, politics and impact.
Even crypto algorithms rely on unproven assumptions for their security, even ignoring e.g. side-channel attacks.
Earlier quoted context omitted.
yes ALSR, sorry, acronym fail on my part. So ALSR does randomize bindings on each execution ?
Yes. If I run e.g. `ldd /bin/bash` multiple times, it shows different memory addresses each time. That's ASLR.
I'm interested that they didn't list the "old" reason people thought unikernels could be more secure. That is that they could be small enough to be completely written in higher languages. With something like https://github.com/GaloisInc/HaLVM you could bring to bear formal methods in more straight forward ways. This of course left the host still needing to be secured using traditional approaches but that surface area…
Unikernels are not that new. CMS running on VM has existed since the 1960s, with CMS being the unikernel (actually, a unitasking OS about as complex as MS-DOS) and VM being what's now called a hypervisor: Something which multiplexes hardware, but provides no APIs, such that VM guests think they're running alone on bare hardware. (VM can even run VM as a guest, recursively, which is useful for developing the newer ver…
There is what amounts to an "API". The virtualized software thinks it's talking directly to hardware, so the API is just an emulation of that hardware. Since controlling hardware is almost invariably messier than doing system calls, the API is actually more complex.
Therefore, we can evaluate these claims by asking what we know about security breaches on VM/CMS systems.
Here's an HN post I wrote a few years ago, about VM exploits: https://news.ycombinator.com/item?id=9241807
Plenty of exploits to be found, many of which were related to emulation of "I/O channel programs", which are, essentially, System/370 I/O "hardware".
Earlier quoted context omitted.
Just like an operating-system executes processes, a VMM executes unikernels. An operating system is responsible for randomizing the layout of processes in memory. Shouldn't the actual question here be "Does my hypervisor implement some mechanism for randomizing the layout of my unikernel?"
I don't think it matters whether it's implemented by the hypervisor or the unikernel since it's all open source. But for compatibility with existing hypervisors/clouds one could imagine a boot loader that loads the main unikernel at a random address, sets up page tables with NX, and then makes a one-way transition to ring 3 so that the page tables cannot be modified.
True - I suppose I'm trying to hold onto the "kernel:hypervisor :: process:unikernel" analogy here for no good reason. Following it suggested that it might be the hypervisor's responsibility.
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…
Hi author here. I agree wholeheartedly. I wasn't thinking in absolutes, but I absolutely can understand how it could read that way. I could have titled the post "Unikernels are resonably secure", but then nobody would have read it. I was doubtful about mentioning the lack of shell. Technically it doesn't really do much in terms of security, but it does make a compromise harder. And currently, where we stand, a lot of…
> IncludeOS is a clean-slate unikernel written in C++ with performance and security in mind. One of those things doesn't belong there. Guess which?