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

121–130 of 142 posts

Re: Unikernels are secure

#121

Post by eutectic »

warkdarrior wrote: post #84
eutectic wrote: post #19

Earlier quoted context omitted.

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

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

I was talking more about cryptographic hardness assumptions such as the existence of one-way functions. Nevertheless, even in http://www.ccs.neu.edu/home/wichs/thesis.pdf, which was the first search result for that term, one of the first phrases is 'subject only to the constraint that the rate of leakage is bounded'.

Re: Unikernels are secure

#122

Post by jeshwanth »

numbsafari wrote: post #58
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…

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

Re: Unikernels are secure

#123

Post by staticassertion »

meson2k wrote: post #12

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

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.

Re: Unikernels are secure

#124

Post by xorcist »

robotresearcher wrote: post #106
notacoward wrote: post #103

Earlier quoted context omitted.

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

How is this done? 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!

I have no idea, but couldn't you use some part of the software you just compromised that makes syscalls?

Re: Unikernels are secure

#125

Post by tptacek »

mato wrote: post #118
tptacek wrote: post #35

Earlier quoted context omitted.

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.

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 rem…

What difference does it make if there's no fork/exec? Back in 1999 we had MOSDEF and CORE IMPACT, both of which used staged loaders to boot up a language runtime in a remote process after compromising it with a stack overflow. In a broader sense this is stuff that viruses had been doing for about 8 years prior to that.

Only executing native code is no defense at all. You're not even stopping attackers from the '90s like that.

ROP is only a hardship until exploit code can find a way to allocate executable memory or hook the program's own dynamic execution (note: this is not necessarily a "JIT" or "eval") capabilities. ASLR only matters when exploits can't find infoleaks.

Really, what you're describing here is the browser security model. When staffed by the largest, best security teams in the world, the browser security model almost works.

Re: Unikernels are secure

#126

Post by silly-silly »

eadmund wrote: post #105
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…

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

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

Re: Unikernels are secure

#127

Post by weberc2 »

floobyhoob wrote: post #95
weberc2 wrote: post #94

Earlier quoted context omitted.

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

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…

I understand the use case; I just don't understand why operating as an HTTP server isn't sufficient?

Re: Unikernels are secure

#128

Post by rf15 »

makapuf wrote: post #115
rf15 wrote: post #26

Earlier quoted context omitted.

No, it's like saying it is round "if and only if" we can prove that it is round.

Which the scientifical method tells you to verify experimentally, i.e. with tests.

No, the point is: The sphere doesn't care if you can prove if it is a sphere or not, it stays a sphere. If you CAN TELL if it is (or not) is a different matter entirely, so it doesn't work that you say "if and only if it is proven" when you make claims about something having a certain property.

i.e. Just because I can't tell if you have two hands to type this doesn't mean you don't have them.

"You have two hands if and only if there's a formal proof that you have two hands"

Re: Unikernels are secure

#129

Post by mato »

tptacek wrote: post #125
mato wrote: post #118

Earlier quoted context omitted.

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 rem…

What difference does it make if there's no fork/exec? Back in 1999 we had MOSDEF and CORE IMPACT, both of which used staged loaders to boot up a language runtime in a remote process after compromising it with a stack overflow. In a broader sense this is stuff that viruses had been doing for about 8 years prior to that. Only executing native code is no defense at all. You're not even stopping attackers from the '90s l…

> Back in 1999 we had MOSDEF and CORE IMPACT (...)

I'm not familiar with these. Googling "MOSDEF attack" suggests Massive Attack songs and "CORE IMPACT" various products by Core Security, I presume you're referring to neither? :-)

> Only executing native code is no defense at all. You're not even stopping attackers from the '90s like that.

> ROP is only a hardship until exploit code can find a way to allocate executable memory or hook the program's own dynamic execution (...)

Only executing native code loaded at deployment time, i.e. presumably from a trusted source. What I meant by "immutable page tables" is that after loading the unikernel image the set of executable pages is fixed, and all of those are read only. This is not something current unikernels do, but that's more due to lack of development time rather than any inherent implementation complexity.

If there is no way for the exploit code to ask the hypervisor for new executable pages or overwrite existing ones then the amount of damage it can do and its ability to persist in the running system is greatly reduced.

> Really, what you're describing here is the browser security model. When staffed by the largest, best security teams in the world, the browser security model almost works.

It's similar but not the same. The browser security model breaks down in a large part due to exposing way too many APIs, most of which are too complex to sensibly audit. Linux system calls have a similar problem, which is why you have to hand-craft things like seccomp profiles to match your particular application.

Unikernels (as used to implement network services) lend themselves extremely well to running on top of a well defined API / sandbox boundary, designed with security in mind. Again, we're not there yet, but the steps we need to explore in this direction are fairly clear.

Re: Unikernels are secure

#130

Post by robotresearcher »

xorcist wrote: post #124
robotresearcher wrote: post #106

Earlier quoted context omitted.

How is this done? 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!

I have no idea, but couldn't you use some part of the software you just compromised that makes syscalls?

There are no syscalls as the fine article explains.
Post reply on HN