Breaking news: Hipster bloggers use all-organic artisanal application stacks to replace an operating system with a smaller, more intimate operating system that thinks the 90s were just so cool, man, even if they have to spend all their time to reinvent the wheel without any obvious benefit. Film at 11.
Do you have objections against the attack surface argument?
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.
Actually, if what you want is to avoid heat loss, reducing the number and area of windows is a pretty good strategy. Simpler (picture) windows are also easier to secure than complex ones that can be forced open.
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.
Yes, one wonders why peterwwillis hasn't, as he suggests as an easy approach, "audited" OpenSSL himself and found the heartbleed in process. And that "over one weekend."
Please do audit the Mirage OS as modified in the article and show what you find. I'm interested to see how you can claim that the OS which doesn't even have a file system, has only drivers for virtual hardware and not even code for starting a process isn't more secure than any other big solution. Above all, the code based on the functional language. It's closest to what we have to have a provably secure system.
This is the same security fallacy as I mentioned twice before, just reworded. Removing code does not leave you with secure code. There's still a memory allocator, I/O layer, a tcp/ip stack, DHCP protocol+service, HTTP protocol+service, HTTPS protocol+service (edit: sorry, there's no HTTPS support in Mirage), and all of the miscellaneous parts required to run those bits, which all have security concerns.
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.
Until you present some proof of any vulnerability, your word has not more weight than mine, and I claim that you don't understand what you talk about and that you can't find a way to compromise her setup.
Extra software that is never used does not increase complexity. A Linux distribution is not a large, complex project. I'm guessing your heat loss analogy is about performance? Do benchmarks and get back to me.
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.
The article was never about "easier" solution. Where have you read anything about "easy"? It's an extreme solution. Think at least once about that please: the "OS" from which she serves her site doesn't even have a file system. Doesn't have users. Doesn't have new processes. Doesn't have drivers for different actual hardware, only for the virtual one.
mirage is anything but retro; it's an attempt to build an operating system optimised for running network applications by picking out just the pieces you need and implementing them efficiently and securely. more excitingly (at least to me) it's an os and ecosystem being built from the ground up in ocaml rather than c.
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.
Hell, isn't it what it's all about? Trying out new things, even if they are impractical, challenge yourself and learn things, and maybe leave them a bit less broken. It's a bit dispiriting to read "get-off-my-lawn"-style answers, especially about something genuinely interesting and which isn't filling half the frontpage at any given time.
did you even read the post? she spent several paragraphs talking about the attack-resistance benefits running on a unikernel provided.
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.
Possibly, but she can't modify the code of S3 and whereas she can modify the unikernel as much as she wants. Only at this moment, the static pages are enough.
Storing something on S3 has order of magnitude less hacker points than doing this.
it's not really a discussion point, it's sneering at people for "reinventing the wheel", when the entire point of mirageos is to start from scratch and try to make a better wheel. i'm really having a "how do other people not find this as exciting as i do?!" moment here.
Unikernels are pretty much the future of cloud deployment. Why even bother with all the pieces a standard OS distro comes with when you can compile and link together only the things you need to run your specific application? Deployment and configuration are a breeze, the atrack surface us reduced and so is the total amount of code running and the OS image size. See also the work the NetBSD devs have been doing with building unikernels out of rump kernel drivers.
Oh, and you should really be eating paleo, local, and organic.
Thanks! It's a "high-level summary" of all necessary steps needed to host the site with the described technologies. Reading it:
"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?
So what's the advantage of doing this over just using S3/CloudFront static hosting? In either case your attack surface is essentially that of AWS itself and S3 hosting seems like it would be much simpler (and almost certainly much cheaper).
In theory you can use a unikernel to run a rails app, python app, etc. This post uses static sites as the example but I think it's more of a "prep" than the end all be all use.
I don't think Mirage is quite mature enough for that yet, but eventually, it should be possible to run at least an Ocsigen/Eliom (OCaml web framework) on it.
Her setup is based on the unikernel which is practically "a custom minimal OS doing only one thing," having only Xen under. Knowing that Xen is under it it doesn't even have to have to customize the drivers for the different hardware -- Xen does that. Docker container has a bunch of regular stuff which runs on Linux, but separated from the other stuff.
Very cool idea. It actually reminds me of how the Azure PaaS offering (Web & Worker Roles) work - you just send up the code you want to run and they run it. It's different than the unikernel because under the covers Azure is running a full Windows OS, but from a user perspective it's not all that different.
Seems like an ok 'Hello, Unikernel' article if a bit forced but her point about bots mining on AWS actually undermines her deployment strategy: the miners have been compromising AWS credentials/security NOT boxes hosted on AWS. They don't want your little t2.micro instance running a static server. They startup new c3.8xlarge instances and deploy their software.
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.
While obviously overkill to run a small blog it certainly feels tempting. If could be efficiently automated surely it is worth a try.
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.
37 comments
[ 3.3 ms ] story [ 84.3 ms ] threadDo 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.
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.
But using the word is a good way of introducing a joke.
"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?
"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
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.