"Secure" and yet they aren't even using a memory safe language such as Rust.
Unikernels are secure
61–70 of 142 posts
Re: Unikernels are secure
#62Earlier quoted context omitted.
"Secure" sounds like a binary attribute but it's actually not. A formal proof doesn't save you from errors in the specification. At some point you need trust, the amount of trust needed is inversely proportional to the security.
Without a formal proof there is no measure of correctness at all.
Lots of passing tests mean nothing to you?
Re: Unikernels are secure
#63A unikernel is running a single process in a single address space. So yes, if you compromise the app you compromise the whole system but the whole system is the app.
That's not entirely true in practice. I'm currently playing with rump kernels deployed on top of seL4's hypervisor to give my platform the security posture of a unikernel inside the security posture of seL4 VM isolation. You could potentially compromise the rump kernel, but you still wouldn't be able to break out of the VM's isolation context.
The app is still compromised.
On top of that, you didn't get to reap the benefits of any of the protections you get from a proper Kernel like Ring 3 execution, NX bits on pages, guard pages on the stack, etc.
Re: Unikernels are secure
#64Earlier 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 never bothered to check, what a m... I am. Thanks a lot :)
Re: Unikernels are secure
#65Earlier 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.
Also worth mentioning that `ldd` only demonstrates how shared libraries are mmap'ed at randomized locations. Stack and heap allocations are also randomized at execution time.
Re: Unikernels are secure
#66In addition to the blog post, there's an interesting discussion on Github that happened before the blog post was published: https://github.com/Unikernel-Systems/unikernel.org/pull/45
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 other userspace code.
As root, you still have to run the kernel. As Ring 0, you can replace the kernel. Or run your own OS.
Re: Unikernels are secure
#67"No system calls" Yeah, they're direct function calls now. How exactly is that more secure? The author's right that many traditional exploit paths are gone, but only because they've been replaced by even easier ones.
Because you don't know how to call the functions, as explained in the article. To call a function, you need to know its address among other things. And you don't, since the address was decided at random at build time (or even boot time in some systems).
Re: Unikernels are secure
#68> 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?
C++ (who uses that when perfectly good C is available?)
:)
Re: Unikernels are secure
#69> 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…
Pardon me, but this seems pretty different from the use cases of DEP. Perhaps you'd like to expound further on this.
Imagine a standard webapp deployed via CI. Each time any feature is shipped the entire layout is randomized and then deployed. While a redundant system will have multiple copies with an identical layout, that layout will rotate. If required, a CI process could rebuild the system into N parallel groups with N different layouts (your degree of paranoia is the salt to taste here).
Given that these systems are frequently rebuilt with each deploy it seems nearly identical to me in practice to a relink-on-run.
Re: Unikernels are secure
#70I 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 the security comes from things being really, really hard to compromise. Guessing adresses, not having a shell, potentially no filesystem, etc.