Earlier quoted context omitted.
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 req…
What's the use case for booting an entire OS to service a request?
Unikernels are secure
101–110 of 142 posts
Re: Unikernels are secure
#102> 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…
In regards to what could be rebuilt, computer security is plagued with "coulds". What matters is what is done.
Re: Unikernels are secure
#103"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
#104What 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.
Re: Unikernels are secure
#105So, 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…
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?
Re: Unikernels are secure
#106Earlier quoted context omitted.
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).
There are other ways to find functions besides knowing their addresses a priori.
I think kernels try not to leak the address of system calls at run time, and if they are scattered around in a 64bit address space they are tough to search for. Educate me!
Re: Unikernels are secure
#107Earlier quoted context omitted.
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…
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.
I will not play this "Use OpenBSD because it has a new technique that is fashionable" game that I know is being played.
Custom baremetal custon built VMs is not really in the business of distribution appliance images. That's Docker. Different use case. So what IS done is a workflow to rebuild these images when they change.
And that's often. Their HTTP routing table is literally baked into the image. They're not "reusable" for the most part.
Re: Unikernels are secure
#108Earlier 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.
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
#109Earlier quoted context omitted.
Lots of passing tests mean nothing to you?
When an exploit only needs one edge case not handled right? No, lots of unit tests means nothing. Maybe less than nothing due to the false sense of security they seem to give you.