HN Gopher Feed (2017-07-10) - page 1 of 10 ___________________________________________________________________
Unikernels are secure
139 points by ingve
http://unikernel.org/blog/2017/unikernels-are-secure___________________________________________________________________
eriknstr - 6 hours ago
> What we need is this:> * packet interface for the network> * a
block interface for some storage> * a serial port to output console
dataSome applications need additional devices, such as for example
hardware RNG, atomic clocks and/or GPGPU.
kasey_junk - 3 hours 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 - 1 hours 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.
PieSquared - 6 hours 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 - 6 hours 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?
tscs37 - 4 hours 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 - 6 hours ago
It's secure if and only if there's a formal proof.
adrianN - 6 hours 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.
dreamdu5t - 6 hours ago
Without a formal proof there is no measure of correctness at
all.
adrianN - 4 hours ago
Lots of passing tests mean nothing to you?
monocasa - 2 hours ago
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.
floatboth - 2 hours ago
Who proves the proof though? :)
elygre - 6 hours ago
That's like saying that the world was flat before they could
prove that it is round.
Spivak - 6 hours ago
No, that's like saying that we don't know what shape the world
is before we could prove that it is round.
rf15 - 6 hours ago
No, it's like saying it is round "if and only if" we can
prove that it is round.
geofft - 6 hours 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.
antientropic - 5 hours 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.
geofft - 41 minutes 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.
tptacek - 6 hours 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.
notacoward - 5 hours 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.
wmf - 5 hours 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.
robotresearcher - 4 hours 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).
mtgx - 6 hours 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?
willtim - 43 minutes ago
Yes it reads like satire. MirageOS, having been written in OCaml,
would have a better claim to being written with security in mind.
dmitrygr - 4 hours ago
C++ (who uses that when perfectly good C is available?):)
Cieplak - 6 hours 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.
nkozyra - 6 hours 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?
PeterisP - 6 hours 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.
benchaney - 6 hours ago
> if there were a buffer overflow in a unikernel process,
wouldn't it potentially give the exploit full-system accessYes>
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.
digi_owl - 6 hours 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.
perbu - 3 hours 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 - 6 hours 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-four - 6 hours 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 - 6 hours 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.
PeterisP - 6 hours 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.
benmmurphy - 6 hours 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
:/
msla - 5 hours 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 - 1 hours 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=9241807Plenty 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".
msla - 20 minutes 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.
nkozyra - 6 hours 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."
jeshwanth - 5 hours ago
Looks to be unikernel is just a RTOS, why the name unikernel then ?
Whats the difference with RTOS?
numbsafari - 5 hours 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.
im_down_w_otp - 5 hours ago
A RTOS means a specific thing regarding timing (and sometimes
fairness) guarantees. A unikernel isn't that.
futurix - 3 hours ago
Generalisations are generalising.
RRRA - 4 hours 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 - 4 hours ago
Claiming something is secure is more like claiming an over unity
perpetual machine
peterwwillis - 6 hours 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!"
wglb - 5 hours 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.
cwp - 2 hours 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.
perbu - 3 hours 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.
wglb - 3 hours 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.
dvfjsdhgfv - 1 hours 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.
dvfjsdhgfv - 5 hours ago
My thoughts exactly. If they wrote "more secure", this would make
more sense. In the current form it's just boasting.
api - 5 hours 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.
FungalRaincloud - 6 hours 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.
y7 - 6 hours 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.
bmc7505 - 6 hours 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 - 5 hours 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.
vertex-four - 6 hours 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 - 6 hours ago
https://en.wikipedia.org/wiki/Provable_securityYou can prove
that it's secure in that the algorithm itself does not leak
information.
klodolph - 5 hours ago
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.
taeric - 6 hours ago
Yeah, but this is not what most people think of when they
think secure, is it? That is, this proves that people have
to actually break an algorithm to know what it is protecting.
This does nothing to show that an algorithm is
unbreakable.(As an example of my understanding, rot13 does
nothing to randomize distribution of characters, so it
"leaks" information about what it has modified. This sort of
leakage can be proven as absent from your algorithm.
Anything else is a bit tougher.)
eutectic - 6 hours ago
Even crypto algorithms rely on unproven assumptions for their
security, even ignoring e.g. side-channel attacks.
warkdarrior - 2 hours ago
Not true. Look up "resilience to information leakage".
nneonneo - 6 hours 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 - 5 hours 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
wmf - 5 hours 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.
language - 3 hours 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?"
wmf - 2 hours ago
I don't think it matters whether it's implemented by the
hypervisor or the unikernel since it's all open source. But
for compatibility with existing hypervisors/clouds one could
imagine a boot loader that loads the main unikernel at a
random address, sets up page tables with NX, and then makes a
one-way transition to ring 3 so that the page tables cannot
be modified.
language - 1 hours ago
> one could imagine a boot loader that loads the main
unikernel at a random address, sets up page tables with NX,
and then makes a one-way transition to ring 3True - I
suppose I'm trying to hold onto the "kernel:hypervisor ::
process:unikernel" analogy here for no good reason.
Following it suggested that it might be the hypervisor's
responsibility.
perbu - 3 hours 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.
meson2k - 6 hours 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.
KirinDave - 3 hours 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.
agumonkey - 6 hours ago
is linux randomizing is per exec ?ps: BSD have started to
randomize at boot time, fun times
geofft - 6 hours 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.
_joel - 6 hours ago
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)
agumonkey - 5 hours ago
yes ALSR, sorry, acronym fail on my part. So ALSR does
randomize bindings on each execution ?
majewsky - 5 hours ago
Yes. If I run e.g. `ldd /bin/bash` multiple times, it
shows different memory addresses each time. That's ASLR.
agumonkey - 4 hours ago
I never bothered to check, what a m... I am. Thanks a lot
:)
language - 4 hours ago
Also worth mentioning that `ldd` only demonstrates how
shared libraries are mmap'ed at randomized locations.
Stack and heap allocations are also randomized at
execution time.
strcat - 1 hours ago
cat /proc/self/maps is a better way to see that. If it's
built with PIE, the executable base is randomized. Some
distributions use full ASLR across the board (Alpine,
Android, ChromeOS, Hardened Gentoo) while others don't
yet enable PIE globally or have only recently started and
it isn't all pushed out yet (OpenSUSE, Fedora, Debian).
dreamdu5t - 6 hours 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.
perbu - 3 hours 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.
willtim - 37 minutes 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.
kmicklas - 4 hours ago
"Secure" and yet they aren't even using a memory safe language such
as Rust.
rdtsc - 3 hours 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 - 3 hours 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"?
floobyhoob - 40 minutes 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.
weberc2 - 35 minutes ago
Why are millisecond bit times necessary? Linux doesn't boot in a
millisecond...
floobyhoob - 33 minutes 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.
corndoge - 8 minutes ago
What's the use case for booting an entire OS to service a
request?
sethev - 6 hours 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_otp - 5 hours 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.
tscs37 - 4 hours 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.
dmitrygr - 6 hours 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
wmf - 5 hours 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.