"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.
Unikernels are secure
41–50 of 142 posts
Re: Unikernels are secure
#42Earlier quoted context omitted.
> 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.
KALSR's not the same as ASLR (although ideologically related). ALSR has been around for a good number of years in userspace via randomize_va_space sysctl (edit I presume that's what the poster above mentioned re: per exec)
yes ALSR, sorry, acronym fail on my part. So ALSR does randomize bindings on each execution ?
Re: Unikernels are secure
#43So, 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…
> 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.
Re: Unikernels are secure
#44So 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.
Re: Unikernels are secure
#45Earlier quoted context omitted.
KALSR's not the same as ASLR (although ideologically related). ALSR has been around for a good number of years in userspace via randomize_va_space sysctl (edit I presume that's what the poster above mentioned re: per exec)
yes ALSR, sorry, acronym fail on my part. So ALSR does randomize bindings on each execution ?
Yes. If I run e.g. `ldd /bin/bash` multiple times, it shows different memory addresses each time. That's ASLR.
Re: Unikernels are secure
#46Earlier quoted context omitted.
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.
https://en.wikipedia.org/wiki/Provable_security You can prove that it's secure in that the algorithm itself does not leak information.
With some exceptions, those proofs make assumptions about their primitives like having block ciphers be "unpredictable permutations" or having hash functions be "random oracles". These proofs also make assumptions that information doesn't leak in other ways (like BEAST, heartbleed, timing attacks, poor entropy sources, etc).
In other words, those proofs don't have as much real-world significance as you'd like.
Re: Unikernels are secure
#47The 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
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.
Re: Unikernels are secure
#48Unikernels 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.
Re: Unikernels are secure
#49> 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.
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.
Re: Unikernels are secure
#50Looks to be unikernel is just a RTOS, why the name unikernel then ? Whats the difference with RTOS?