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

71–80 of 142 posts

Re: Unikernels are secure

#71

Post by perbu »

wmf wrote: post #52
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.

IncludeOS has ASLR. Or as close to ASLR as you can get without dynamic linking. We randomize the layout when we link. And since we typically re-link the image on each configuration change in a network of 1000s VMs each one will have a different memory layout.

Re: Unikernels are secure

#72

Post by perbu »

dreamdu5t wrote: post #13

Hard to take claims of security seriously for untyped languages which are not provably correct and lack a denotational semantics. Let's start by provably not compiling buffer overflows and memory overreads considering those are the vast majority of RCE and privilege escalation.

C++ is strongly typed. I believe there are frameworks that will give you denotational semantics in C++.

It shouldn't surprise anyone that feature X is available in C++. But I acknowledge there are tons of shotguns strewn around everywhere in C++ so you can blow your feet off.

Re: Unikernels are secure

#73

Post by perbu »

digi_owl wrote: post #11
Cieplak wrote: post #5

Hypothetically, if there were a buffer overflow in a unikernel process, wouldn't it potentially give the exploit full-system access, whereas a normal operating system would detect the out-of-bounds memory access and kill the process? I'm sorry if this is an ignorant question.

Best i can tell, unikernels are a reaction to the shift from VMs to containers in cloud services. This by pairing down the content of a VM to the bare minimum. Meaning that if you have a buffer overflow or similar, all you could access was what was in the VM (unless you also happen to pack a VM escape). That said, i can't help think "DOS in a can" whenever i read about unikernels.

If it wasn't for the negative connotations people have with DOS I'd say it a lot more. Implementing a unikernel chain loader and a simple shell would be quite simple. That would be quite DOS-like.

IncludeOS actually came out of a research need to stress-test hypervisors and run 10000 VMs on a single host. Since it is a clean slate system it has some different characteristics and those can be exploited in certain use cases and so people have kept on working on it.

Re: Unikernels are secure

#74

Post by rdtsc »

> There are two aspects of unikernel security. There are two aspects of unikernel security. One is the vector into the VM and the other is the vector from the VM into the hypervisor.

The "vector into the VM" might not be as obvious. For example, in a network security contest in college I compromised the source repository of the server to give my team an advantage and won. That was before git it was just a folder on the server. Others argued it wasn't fair but the instructor sided with me since that's a plausible scenario in real life.

There also tempest-like attacks for extracting private keys and such, so it's there at also at least the 3rd vector - from VM to the hardware as well. And forth from VM to the network (but I guess these can be subsumed in the "to the hypervisor" case).

Re: Unikernels are secure

#75

Post by skywhopper »

So to summarize, unikernels stop a couple of attack vectors (syscalls and running other programs (notably shells) that are loadable from well-known paths). Address randomization is not unique to unikernels, and the other benefits are theoretical for the time being until hypervisors provide more unikernel support (though the mention of paravirtualization makes me think performance (particularly network) in this theroetical hyper-restricted mode will be poor).

While I certainly sympathize with the idea that the typical kitchen-sink deployment of a full suite of administrative/troubleshooting/build tools on an application server is a security risk, it seems the actual improvements enumerated here are relatively small potatoes.

Apologies for not knowing a lot about the state of the art here, but I'm curious about how these unikernels address VM-internal security (eg, network, filesystem, inter-process level stuff). Do you farm all of that out to the hypervisor? Design around the lack of it? _Is_ there even "inter-process stuff"?

Re: Unikernels are secure

#76

Post by language »

wmf wrote: post #52
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.

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

Re: Unikernels are secure

#77

Post by kasey_junk »

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 was smaller.

I'd buy that you can't list that in an article about why all unikernels are already secure, but that seemed to be the heart of the pitch to me when I first started hearing it.

Re: Unikernels are secure

#79

Post by wglb »

perbu wrote: post #70
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…

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…

With "Unikernels are reasonably secure", but then nobody would have read it., you might also take into account whether the audience, having read it, are happy that they did. The title sounded pretty absolute.

So you do have a noble goal. When I am asked to assess software, to gain a first order approximation, I often look at the culture of the organization that produced it. On the high end, that often translates to some sort of formal process involving un-fun letters like 'ISO' and 'SOC'.

For smaller organizations, or OSS software, I try to get a feel for how the developers seem to be thinking about security. Some of the cultural things I see in your writeup are encouraging--Smaller Codebase, Removing hardware emulation, Cutting off access to ring 0--all bode well for how you are thinking about producing secure software.

But there are some things that are missing from your description. What is your development process? In particular how and when do you attack your assumptions about how the code actually works? What flaws have you found in your testing? Zero findings could mean 1) it wasn't tested 2) it wasn't tested very hard 3) the testers were not very good at security testing.

And as OpenBSD's history has illustrated, some things are totally secure until they aren't.

Re: Unikernels are secure

#80

Post by cwp »

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…

Yes, exactly. The article would be much stronger if it also covered ways in which unikernels either don't improve security, or are actually more vulnerable.
Post reply on HN