Attack Surface: Why I Unikernel, Part 1
somerandomidiot.com
somerandomidiot.com
"Unikernels: Rise of the Virtual Library Operating System"
http://queue.acm.org/detail.cfm?id=2566628
It got only a few comments on HN 116 days ago: https://news.ycombinator.com/item?id=8025493
"I start up the build host, then once it’s responding, I scp my unikernel, mir-www.xen, over to its filesystem. The blog is currently about 17 megabytes (mostly high-resolution embroidery photos), so this is starting to take a while; soon I’ll have to do something smarter."
"Each deployment makes a 1GB snapshot, so soon I’ll have enough snapshots on EC2 that I’ll have to go in and delete a few."
What's the size of the final binary that actually runs? 17 MB or 1 GB?
She's still hosting this thing in AWS so she's still vulnerable and no amount of Unikerneling is going to save her from that attack vector.
Sorry for the pun and creating a verb out of a noun.
However, what I'm more interested in is how Mirage works for, say, more practical tasks. It is quite some time already after it came up the first time, there were few blog posts about how to do this or that on Mirage OS, yet I never saw any real benchmarking. Is Mirage more/less/about-the-same effective in serving static content than nginx on Linux? Is it any worse/better than CloudFron static hosting for that purpose? How about real apps on multiple nodes using Mirage? How about it performing on ARM (as I understand that's still largely an experiment, but anyway, it is interesting enough topic to talk about)? Never saw an analysis of it by any actual security professional as well. Essentially speaking, I'm a bit upset that such an interesting project gathers somewhat less attention than, it feels to me, it should.
also, when did people here start looking down on hacking for the sheer joy of it? personally, i found this post pretty inspiring; i've been looking for people who are doing stuff with mirage other than hacking on mirage itself.
Storing something on S3 has order of magnitude less hacker points than doing this.
Oh, and you should really be eating paleo, local, and organic.
Do you think that running a full-blown OS in a virtual machine is much better than a small dedicated OS? Do you think that overhead of userspace isolation is justified for a single task in a virtual machine?
First of all, lowering attack surface is the least intelligent way to improve security. It's like you have a house with a lot of windows that people could break into, so you cut the house in half to reduce the number of windows. What works much better than that is auditing and hardening the security of the house and its windows and making strategic decisions about how they work.
For example, many people argue you should remove compilers from your system so attackers can't compile exploits on the host. But now the attacker can just push code there, or try a bunch of code in trial-by-error.
Other people argue that any piece of software that isn't necessary should be removed, in case one of them has a vulnerability that could be used against you. Those vulns (for example, priv escalation vulns) could be eliminated by a simple audit of permissions, MAC rules or hardening patches, which would also drastically increase the overall security of the system. But people pick what appears like a simple solution because they don't want to think about it.
I think you use the tool that works for your use case.
If you were designing flight control software for the space shuttle, a whole virtual machine + OS might be overkill for your application, because you have a very specific set of operations to deal with and you need it done in a very specific environment, and you probably won't need to dynamically allocate extra resources in the middle of flight.
On the other hand, if you're just serving static http content, your requirements are very minimal so you can use just about anything. Any OS, any web server, any content provider, any security configuration, etc. Due to its very narrow set of operations and few requirements, it's really easy to secure no matter what you use.
In this guy's case he could have just read a book on SELinux and written a policy for a ridiculously secure web host over a weekend. Instead he's using some obscure bleeding-edge pseudo-operating system which he'll probably never use for anything else once he realizes how impractical it is, and getting marginal (if any) security benefit. He even admits he DoS'd it by accident. The only reason he's doing this is he thinks it's retro and cool.
It's the same with roofs: want to avoid leaks? Make your roof as simple as possible, with as few penetrations as possible.
Very large, complicated projects are harder to audit, to the point of infeasibility (OpenSSL in its pre-heartbleed form comes to mind).
Originally, a lot of people who were against "software bloat" (like Wirth with Oberon) did it because they wanted to run stuff on affordable computers (minicomputers rather than mainframes in the 1970s, microcomputer rather than workstations in the 1980s). That reason disappeared thanks to computing power.
But now, with the internet as Serious Business where attackers create a constant barrage, it doesn't make much sense to run a "full OS" created for minis and workstations when all you want to do is serve some Web content.
Unix-as-a-server-OS is a historical accident borne of the BSD implementation of TCP/IP and the usefulness of Unix-running hardware in the early days of the net.
Speaking of OpenSSL there's even this:
http://openmirage.org/blog/introducing-ocaml-tls
Transport layer security (TLS) in pure OCaml, useful for MirageOS.
These are the exact same things you expose to vulnerability in a regular Unix OS, and have the exact same potential flaws. Code doesn't become more secure just because you have to use an ABI. Computers (and security) are not magic.
And provable security, really? First of all, proofs have bugs. Second, no real-world attackers have ever been stopped by a provably secure design (partly because implementation is never provably secure). And finally, Mirage was only written to be a statically-typed low-overhead binary that encourages more code reuse. It was not designed with security in mind. That shows that it's nowhere near provable security to begin with, and real-world attackers won't care either way.
If all you want to do is serve (not run) web content, put it on Geocities. Creating your own Geocities is not more secure or easier.
also note that in getting her blog up and running this way she has (a) gained some familiarity with mirageos and (b) contributed pieces back to the ecosystem that will let the next person who wants to do the same thing have an easier time of it.
linux was similarly impractical when it started out; early adopters who built and contributed valuable tools to it could doubtless have had an easier time finding existing software in an established environment that would let them get their job done quickly. personally, i'm very glad they decided to help linux grow instead.
But using the word is a good way of introducing a joke.