Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unikernels are secure

unikernel.org

Post reply on HN
Print view View original

51–60 of 142 posts

Re: Unikernels are secure

#51

Post by swordswinger12 »

bmc7505 wrote: post #32
FungalRaincloud wrote: post #10

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.

Unless you're dealing with OTPs, hashing, or lattice-based schemes, there are almost no information theoretical guarantees in encryption. For a field that uses math so heavily, it's surprising how rare traditional proofs are in the cryptology literature. Most encryption schemes are specifically designed to be hard to analyze.

This isn't for lack of trying on the part of cryptographers - unconditional proofs of security for most modern cryptosystems would imply that P and NP are separate. For example, a direct proof that SHA-256 is collision-resistant would imply that one-way functions exist unconditionally.

Re: Unikernels are secure

#52

Post by wmf »

nneonneo wrote: post #33

So, basically, we're going to run all your code at ring0, so a single bug is now either a total DoS (kernel shuts down) or an exploit vector straight to ring0. Although they talk hypothetically about a defense for that involving the MMU, this is not implemented in IncludeOS. The build should not be relied on to be secure either; certain classes of memory disclosure bugs could leak out enough memory to let you work ou…

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.

Re: Unikernels are secure

#53

Post by wglb »

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 about the claims.

Re: Unikernels are secure

#54

Post by wmf »

notacoward wrote: post #41

"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.

They assume that 99% of libc was stripped out at build time. The full network stack is probably there but there might not be much filesystem code.

Re: Unikernels are secure

#55

Post by dvfjsdhgfv »

wglb wrote: post #53

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…

My thoughts exactly. If they wrote "more secure", this would make more sense. In the current form it's just boasting.

Re: Unikernels are secure

#56

Post by im_down_w_otp »

sethev wrote: post #38

A 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.

Re: Unikernels are secure

#58

Post by numbsafari »

jeshwanth wrote: post #50

Looks to be unikernel is just a RTOS, why the name unikernel then ? Whats the difference with RTOS?

A unikernel could be designed as an RTOS, but not all RTOS are unikernels (in fact, I'm not aware that any are). Indeed, QNX, a RTOS, is not implemented using a single address space, nor is your application linked against the kernel and supporting libraries into a unikernel. While it's certainly possible that you could implement an application/unikernel with real-time guarantees, I'm not aware of a specific unikernel implementation that targets that space specifically.

Re: Unikernels are secure

#59

Post by RRRA »

And if you run a Linux kernel with a C app as one, for example, it's probably possible to run a shellcode proxy in memory, even if you can't modify the app code, you could ROP if a big enough buffer overflow is possible on the stack, etc.?
Post reply on HN