"Cappsule is a new kind of hypervisor developed by Quarkslab (to our knowledge, there’s no similar public project). Its goal is to virtualize any software on the fly (e.g. web browser, office suite, media player) into lightweight VMs called cappsules. Attacks are confined inside cappsules and therefore don’t have any impact on the host OS. Applications don’t need to be repackaged, and their usage remain the same for the end user: it’s completely transparent. Moreover, the OS doesn’t need to be reinstalled nor modified ... Cappsule uses hardware virtualization to launch applications into lightweight VMs, which run a copy of the host kernel and have no access to the hardware. If an attacker manages to break into the VM (through a bug in the application for instance), the attack is confined into the VM."
"Traditional virtualization solutions (e.g.: VMware, Xen, KVM) virtualize whole operating systems (such as Windows or Linux), whereas Cappsule virtualizes a running system. VMs launched by Cappsule don’t go through the boot step; they start directly on a running kernel. This particular feature allows an instantaneous launch of VMs. One can think of VMs as forks of the host operating system. In fact, the VMs’ kernel is a copy of the running host kernel. Another particularity is that no VM disk image is required. There’s no need to setup, configure, install, manage and keep new VMs up-to-date. The host filesystem is accessible as Copy-on-Write (with respect to a whitelist of files and folders accessible in read-only or read-write mode).
Every software has security bugs, and Cappsule is no exception. But it is developed from scratch, with the main goal of being secure. With less than 15K lines of code, the attack surface is extremely narrowed in comparison to mainstream hypervisors. Moreover, anything that isn’t vital for the VMs isn’t implemented and certain classes of attacks simply don’t exist. For example, there’s no way to access hardware (through I/O memory, I/O ports, or DMA). Also, there’s no need of instruction emulation: vulnerabilities such as XSA-105 are thus impossible.
"http://stackless.readthedocs.io/en/2.7-slp/library/stackless...
would make it possible to have truly distributed applications. Imagine thousands of tasklets jumping through your filesystem, local network or the internet.
Another interesting property is determinism, which in turn would allow for remote execution and instruction metering - a computation market.
http://e-drexler.com/d/09/00/AgoricsPapers/agoricpapers.html
If the code is fully deterministic, verifying results becomes much simpler, one option is comparing merkle roots over the entire program state, for example:
It was inspired in part by just those agoric papers and meant to grow into supporting that kind of market. It was also designed to be fully deterministic, and included the suspending/serializing you mention (disabled because my first stab at resource accounting for that feature was wrong). It only had a few months of work put into it before I ran out of steam, though. Nowadays Web Assembly seems closest (and much further along), though it abandoned full determinism.
Kragen Sitaker (HN user kragen) posted some interesting ideas about taking advantage of determinism in a platform built for it from the start. He called it Kogluktualuk, but his post seems to have been lost to googling.
I think this is a promising direction still.
IBM was working on that with Java: https://www.ibm.com/developerworks/library/j-multitenant-jav...
Whilst the complexity of the script is limited in what it can do, it seems actually not that hard to imagine some kind of next-gen CDN offering edge scripting to statelessly rewrite requests and responses.
A better design would be to run one Lua VM per tenant, but then we are at totally different set of problems (preemptive multi-tasking between VM's?)
Now even with a 'locked down' Lua VM there is a lot of trust in executing 3rd-party scripts and there might be various attacks.
But as I said, I really could imagine some next-gen CDN allowing paying customers to put Lua scripts in the edge to rewrite requests and responses.
If I were tackling it I would want all the script instances for any given customer to be isolated at a hardware level from other customers too.
Can't you already do that with PaaS providers? Upload your code, create instances across multiple regions, and you're done.
There's an old talk on Security http://millcomputing.com/technology/docs/security/
I have prepared a much more up-to-date whitepaper on this that is going through internal review right now. Afraid we're focusing 99% on sim work at the moment and that 1% for other business is meaning the paper has been 'in review' since last autumn... hmm, have to go push :)
But I'm happy to elaborate if anyone has any security questions.
(Apologies if you're all still suffering from Mill fatigue)
For example, i would love to understand how to take a program, limit the total count time and memory usage of it, and all its children, and be able to clean up after it.
Bonus points if i can limit what directories it can write to.
I'm sure one of these things will do it, but i don't know what level i want.
It has a GCC backend.
