Unikernels are secure

http://unikernel.org/blog/2017/unikernels-are-secure

by ingve • 9 years ago

193 140 9 years ago

dmitrygr2• 9 years ago

The argument that something IS secure is somehow supported by a whole lot of hypotheticals of the form "we could do $X and that would be secure if someone also did $Y".

So say it how it is: unikernels COULD be secure if all this work that needs to be done and we haven't done was done...maybe

wmf4• 9 years ago

That's par for the course. Unikernel people talk about VMs that use megabytes of RAM while cloud providers only provide gigabytes. Unikernel people talk about spawning VMs in tens of milliseconds while clouds take tens of seconds.

PieSquared• 9 years ago

In 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

Danihan• 9 years ago

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?

tscs376• 9 years ago

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.

rwmj• 9 years ago

It's secure if and only if there's a formal proof.

adrianN3• 9 years ago

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

dreamdu5t2• 9 years ago

Without a formal proof there is no measure of correctness at all.

elygre• 9 years ago

That's like saying that the world was flat before they could prove that it is round.

Spivak• 9 years ago

No, that's like saying that we don't know what shape the world is before we could prove that it is round.

floatboth• 9 years ago

Who proves the proof though? :)

Cieplak• 9 years ago

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.

nkozyra2• 9 years ago

I'm not super familiar with this, but it seems like the question is what is "full-system" in this case if each application is sandboxed with its own embedded kernel? I mean there's no shell, ostensibly all other applications and system functions are bundled similarly, right?

PeterisP2• 9 years ago

It'd make exploits more difficult, but you'd still be able to upload your own code to do whatever you want.

The trouble is that instead of uploading "/bin/sh" you'd have to upload the whole shell which you'd want to run; instead of making a syscall for something that a normal kernel would do but this one doesn't, you'd have to compile and upload appropriate code (including device drivers) to get that done.

It'd be a "bring your own machine code" party.

digi_owl• 9 years ago

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.

perbu4• 9 years ago

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.

leggomylibro• 9 years ago

I could be wrong, but I think this is what Memory Management Units are for, on processor chips. It's one major differentiator between application processors and more embedded ones like Cortex-M or ATMega MCUs, which typically can't run complex modern operating systems. A lot of those chips have a simpler Memory Protection Unit that does basic enforcement of permissions like read+execute, read+write, etc, but they lack the ability to partition memory virtually between a large number of potential 'owners.'

I think - I'm still learning about this embedded stuff.

vertex-four2• 9 years ago

The point is that once you're doing that, and implementing communication between all your separate owners (which map pretty precisely to a reasonable definition of "processes")... you've just implemented another operating system, not a unikernel.

throwaway91111• 9 years ago

Not necessarily. The kernel can run the code in non ring 0, ie in userspace. I can't speak to what is typical, but i imagine you'd get most of your gains by stripping most vulnerable code out of the system outright.

PeterisP2• 9 years ago

First, standard page fault mechanisms would still be in place, that's a processor/architecture feature, so out of bounds memory access would be detected just as in a normal operating system. Of course, a normal operating system does not detect many/most buffer overflows.

In general, you could have a unikernel where it's impossible to get executable buffer overflow because there are no memory pages that are both writable and executable - as the article describes, that'd need some help from the hypervisor for the initialization.

Return oriented programming exploits could work anyway, though.

benchaney• 9 years ago

if there were a buffer overflow in a unikernel process, wouldn't it potentially give the exploit full-system access

Yes

whereas a normal operating system would detect the out-of-bounds memory access and kill the process?

No. A buffer overflow in a normal operating system usually results in the the attacker gaining control over the process that the buffer overflow occurred in. This is not as bad as an attacker gaining full system access, but is generally plenty for an attacker to accomplish their goals.

nkozyra2• 9 years ago

The intro video is somewhat confusing - it indicates that they're secure but if that they're "harder to attack" and says if they are compromised they can be restored. Also, he said "in the future, I believe unikernels will be more or less unbreakable"

I think you could describe that as "more secure" or perhaps more generically "safer" rather than "secure."

FungalRaincloud• 9 years ago

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.

vertex-four2• 9 years ago

Ehh... you can often prove that X algorithm is not susceptible to A, B or C attacks, but you cannot usually prove that the algorithm is "secure" in a fundamental sense.

jacksnipe• 9 years ago

https://en.wikipedia.org/wiki/Provable_security

You can prove that it's secure in that the algorithm itself does not leak information.

eutectic2• 9 years ago

Even crypto algorithms rely on unproven assumptions for their security, even ignoring e.g. side-channel attacks.

warkdarrior• 9 years ago

Not true. Look up "resilience to information leakage".

bmc7505• 9 years ago

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.

swordswinger12• 9 years ago

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.

y7• 9 years ago

This is not true at all for most forms of cryptography. Hash functions and symmetric cryptography are just shown to be resistant against all known attacks. For public-key cryptography there are sometimes security reductions to computational problems that are thought to be hard, but even schemes like RSA do not have such a security proof.

meson2k• 9 years ago

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 on DEP. Randomizing function addresses at each build is useless when it comes to attack mitigation. You need to randomize addresses at each execution.

agumonkey3• 9 years ago

is linux randomizing is per exec ?

ps: BSD have started to randomize at boot time, fun times

geofft4• 9 years ago

is linux randomizing is per exec ?

Not entirely sure what you're meaning to ask, but yes, Linux does KASLR and tries very hard not to leak pointer addresses from the running kernel to unprivileged userspace:

https://lwn.net/Articles/569635/

It's been enabled by default since the upstream 4.12 kernel, and usually well before that in distros.

cyphar2• 9 years ago

Linux randomises userspace executables on per-exec (check out /proc/self/maps).

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

KirinDave2• 9 years ago

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.

throwaway2048• 9 years ago

lots of binaries are distributed as compiled, thats one of the attractions of a unikernel you can just hand people a VM image of whatever the hell you want.

In regards to what could be rebuilt, computer security is plagued with "coulds". What matters is what is done.

staticassertion• 9 years ago

DEP isn't relevant. If you're compiling your own kernel this is a completely viable security technique.

Where it fails is in distros. AFAIK most linux distros do something similar (based on Grsecurity patches) but it's useless because... they then distribute the binary, with everything necessary to get addresses.

But if you're distributing it internally/ it's a secret, yeah, you're going to benefit from that.

dreamdu5t2• 9 years ago

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.

perbu4• 9 years ago

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.

willtim2• 9 years ago

C++ is not "strongly typed" when compared to almost any other statically-typed language, e.g. Ada, OCaml, Haskell or Rust. This is a big part of why it is so insecure.

geofft4• 9 years ago

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.

tptacek2• 9 years ago

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.

mato8• 9 years ago

As one the early users[1] guilty of using the "there is no shell" argument for unikernel security, I agree with what you say. I would rephrase the argument as "there is no fork()/exec()", meaning that a unikernel cannot spawn a new process.

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

antientropic• 9 years ago

I assume it's referring to shell injection attacks. No shell means no shell injections. Of course, it also means that whatever functionality you were calling in a child process now must be in the same address space as the rest of your system. (E.g. rather than call Imagemagick to convert some incoming images from the client, you now must have a library with equivalent functionality in your unikernel.) Whether that's a net security improvement is questionable.

geofft4• 9 years ago

If the argument is supposed to mean "Unikernel applications cannot call system("echo " + user_provided_input)", well, it's pretty easy to do that in conventional applications: just don't call system. If you want to be sure instead of relying on static analysis/code review, rm /bin/sh in your production containers, or something.

Changing all your code to respect this standard is strictly less hard than porting it to a unikernel, because it's one step of porting it to a unikernel.

mtgx• 9 years ago

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?

dmitrygr2• 9 years ago

C++ (who uses that when perfectly good C is available?)

willtim2• 9 years ago

Yes it reads like satire. MirageOS, having been written in OCaml, would have a better claim to being written with security in mind.

benmmurphy• 9 years ago

don't unikernels run everything in ring0. if you run everything in ring0 you can't claim not having system calls is a security feature :/

peterwwillis• 9 years ago

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

Timmy the software developer and his many years of forensic analysis have led him to believe that you need a shell to root something. Literally the entire page's takeaway about security is "It's hard to use, so it's secure!"

nneonneo• 9 years ago

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 out e.g. a ROP payload, which wouldn't require injecting any machine code necessarily. Plus, a long-lived machine, or a single instance deployed across many machines, would present insufficient diversity to protect against a determined attacker. The gist here appears to be the notion that their build diversity gives them most of their security, while they've eliminated most of the traditional defense layers (ASLR, DEP/NX, privilege separation, API isolation, etc.)

If the attacker gets her machine code running in the unikernel environment, it's game over no matter what. The machine code can just directly implement a subset of needed functionality without having to call out to unikernel functions.

In short - this post has a hell of a click bait title but really insufficient evidence to suggest that these are truly "secure".

rrdharan• 9 years ago

In short - this post has a hell of a click bait title but really insufficient evidence to suggest that these are truly "secure".

From the original pull request drafting this post:

While I agree that making hyperbolical claims isn't typically good I'm not sure if it is bad here. There seem to be a tradition in unikernel land with outlandish claims in various blogposts ("Unikernels will kill containers in five years", "Unikernels are unfit for production", etc) so I wrote it with that tone in mind.

https://github.com/Unikernel-Systems/unikernel.org/pull/45

eriknstr2• 9 years ago

If the unikernel people keep up with the hyperbole the potential audience will learn to just ignore most posts about unikernels. Please don't use hyperbole.

wmf4• 9 years ago

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.

perbu4• 9 years ago

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.

language3• 9 years ago

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

eadmund• 9 years ago

So, basically, we're going to run all your code at ring0

From the article: 'However, if the hypervisor can set up the VM before it is booted and provide paravirtualized interfaces to the hardware, we don’t need access to ring 0.'

Which would be pretty sweet, no?

silly-silly• 9 years ago

Ring count doesn't matter when everything is the same ring.

sethev• 9 years ago

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.

im_down_w_otp2• 9 years ago

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.

tscs376• 9 years ago

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.

eriknstr2• 9 years ago

What we need is this:
* packet interface for the network
* a block interface for some storage
* a serial port to output console data

Some applications need additional devices, such as for example hardware RNG, atomic clocks and/or GPGPU.

notacoward2• 9 years ago

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

wmf4• 9 years ago

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.

robotresearcher4• 9 years ago

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

notacoward2• 9 years ago

There are other ways to find functions besides knowing their addresses a priori.

api• 9 years ago

So now the hypervisor is ring0, the cloud provider is the OS, and the OS is the app. IP is the IPC and the Internet is the IPC bus.

I suppose the hypervisor is more minimal and secure. Tenenbaum, thou art avenged.

msla2• 9 years ago

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 version of VM on a machine other people are using for other work.)

Therefore, we can evaluate these claims by asking what we know about security breaches on VM/CMS systems.

PhantomGremlin• 9 years ago

Something which multiplexes hardware, but provides no APIs, such that VM guests think they're running alone on bare hardware.

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

msla2• 9 years ago

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.

Nobody said a hypervisor was completely trivial, but just to be clear, a pure hypervisor wouldn't "emulate" any hardware except what was physically present on the system. The line between "virtual machine" and "hypervisor" and "emulator" are blurry enough as it is, and I'd like to be clear about what the subject of this little thread is.

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

Very interesting. Thank you.

hderms2• 9 years ago

In addition one would have to address hardware virtualization features that would increase security, no?

jeshwanth2• 9 years ago

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

im_down_w_otp2• 9 years ago

A RTOS means a specific thing regarding timing (and sometimes fairness) guarantees. A unikernel isn't that.

numbsafari• 9 years ago

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.

jeshwanth2• 9 years ago

Thanks or your kind reply, I use to find difficult to classify between RTOS and unikernels technically.

wglb2• 9 years ago

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.

dvfjsdhgfv2• 9 years ago

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

perbu4• 9 years ago

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.

wglb2• 9 years ago

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.

dvfjsdhgfv2• 9 years ago

To be fair, I enjoyed reading the article. My conclusion though is that unikernels (an interesting concept in itself) offer only a part of the functionality of a standard OS. As such, it might actually be easier to limit the functionality of a general OS in such a way that it does only what needs to be done and nothing more - and there already some relatively mature solutions for that.

cwp• 9 years ago

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.

xroche• 9 years ago

I would hesitate to call something Secure unless some major pen test effort were engaged to try to break it.

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.

RRRA• 9 years ago

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

m3kw9• 9 years ago

Claiming something is secure is more like claiming an over unity perpetual machine

kmicklas• 9 years ago

"Secure" and yet they aren't even using a memory safe language such as Rust.

rdtsc• 9 years ago

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

skywhopper• 9 years ago

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

kasey_junk• 9 years ago

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.

woodrowbarlow• 9 years ago

well, you also have to keep in mind that this article is written by the CEO of a company producing a particular unikernel implementation -- one that isn't written in a higher language.

futurix• 9 years ago

Generalisations are generalising.

floobyhoob3• 9 years ago

The real problem for unikernels is that they are effectively irrelevant until the major clouds provide millisecond boot times along with appropriate pricing models that charge for execution on a millisecond level basis.

Developers love to write code, but unless unikernel developers start speaking up instead of writing code, the major clouds won't get on board and provide the needed fast boot times plus pricing, which makes all this unikernel code not a lot more than interesting personal / academic projects.

Questions of unikernel security are certainly academic if the cloud infrastructure doesn't run them in the most effective manner.

weberc22• 9 years ago

Why are millisecond bit times necessary? Linux doesn't boot in a millisecond...

floobyhoob3• 9 years ago

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 request, then disappear.

munin• 9 years ago

None of the claims in this have anything to do with the essence of security, they all address the window-dressing of security.

What does it mean for something to be secure? As I see it, for something to be secure, it means that every security invariant holds under all attacker models.

Let's break this down. What's a security invariant, and what's an attacker model?

A security invariant is a statement like "information may only be read by principals authorized to do so" or something similar. The blog post talks about "oh well every exploit I've seen pops a shell with /bin/sh and we don't have /bin/sh so you can't hack it." This attacks the symptom and not the disease. If the attacker is in a position to run /bin/sh you are already at a disadvantage, the attacker was previously going to break your security invariant by spawning a shell and then copying out your secrets. They could instead just use their code execution to read the secrets directly, ala heartbleed, if they are in the same address space.

An attacker model describes the attacker, their motivations/goals, and capabilities. For example, what if the attacker wanted to take your unikernel enabled app and repurpose it into an e-mail spam bot? Well, there isn't a writeable FS and there isn't the ability to exec stuff, so the old model of "copy some files up and run them" won't work. However, is there executable memory in general? Can the application allocate existing executable memory? If the application is, or involves, for example a modern JavaScript interpreter, then it has to be able to do this in some capacity. So now the attacker modifies their methods so that their goal can be achieved in the constraints of this new system.

There is an argument you can make about sandboxing and principle of least privilege, but that argument transcends unikernels really. Look at the sandboxing and separation strategies used by programs like chrome, vsftpd, and qmail. They (in conjunction with enforcement technologies like seccomp-bpf or selinux) can make the same guarantees about the lack of system calls and least privilege.

I'm pretty sure that the title of this post really should be "unikernels are obscure" because that's the layer of protection you're really getting here.

bogomipz• 9 years ago

The article states:

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

kensai• 9 years ago

Why am I reading this "Unicorns"? :D

cyphar2• 9 years ago

One thing that I never understand when I read articles like this (especially this article) is that the "security improvements" that are mentioned are entirely related to there being no userspace (you don't need a shell or syscalls if you don't have a userspace).

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

Unikernels are secure

Related Stories