new trend: Each application in his own VM

[Индарил Шприц]

http://mailman.cs.huji.ac.il/pipermail/linux-il/2013-September/010649.html
   OSv, a new open-source operating system for virtual machines (BSD license)

http://blog.netbsd.org/tnf/entry/running_applications_on_the_xen
   One application per VM approach for FreeBSD

[Joanna Rutkowska]

So can I run Firefox or Thunderbird, or an Open Office application under
OSv or on this NetBSD's rump kernel?

Such approaches are not new, MS also have had a project called
Drawbridge -- see:
http://theinvisiblethings.blogspot.com/2013/08/thoughts-on-intels-upcoming-software.html?showComment=1378805823484#c7091146154501946301

The problem with all those approaches is that they... are either
academic projects or are focused on some narrow subset of applications,
often requiring the apps to be patched, and so don't work for the
mainstream ones like those I mentioned above.

But generally, I would be happy to have such light VMs for running just
one apps in Qubes OS, provided it really worked. We would need to port
qrexec and gui agents to run inside such VM, but besides that this
should fit well with the architecture.

joanna.

[antti....@gmail.com]

On Thursday, September 19, 2013 1:11:18 PM UTC, joanna wrote:

On 09/19/13 14:54, Индарил Шприц wrote:
> http://mailman.cs.huji.ac.il/pipermail/linux-il/2013-September/010649.html
>    OSv, a new open-source operating system for virtual machines (BSD
> license)
>
> http://blog.netbsd.org/tnf/entry/running_applications_on_the_xen
>    One application per VM approach for FreeBSD
>

So can I run Firefox or Thunderbird, or an Open Office application under
OSv or on this NetBSD's rump kernel?

Such approaches are not new, MS also have had a project called
Drawbridge -- see:
http://theinvisiblethings.blogspot.com/2013/08/thoughts-on-intels-upcoming-software.html?showComment=1378805823484#c7091146154501946301

The problem with all those approaches is that they... are either
academic projects or are focused on some narrow subset of applications,
often requiring the apps to be patched, and so don't work for the
mainstream ones like those I mentioned above.

As the author of rump kernels, a real world capable production quality implementation is my first and foremost priority.  The main point of rump kernels is to demonstrate that fundamental software stack components (POSIX syscall interface, TCP/IP, file systems, encrypting disk driver, Soft-RAID, ....) should not be written from scratch no matter how you choose to interconnect those components.  I am not really interested in debating what's the best way to interconnect everything, merely recognize that there are tradeoffs for each model.  For example, the Xen platform linked above is based on throwing unmodified, non-academic kernel components together in a few days out of curiosity to see how it would work.  Turns out it worked really well and people were interested in having a libc and a application API on top so that regular unmodified off-the-internet applications could run.  Getting that working was a few more days of effort.  Then, as is usually the case with non-academic projects, cleanup and polishing required a more significant effort.

That said, there is, as I guess you allude to with your Firefox and Open Office examples, a ton of problems to solve even if the driver/libc-level components are solid.  The point I am trying to make is that these problem sets are complementary.
 

But generally, I would be happy to have such light VMs for running just
one apps in Qubes OS, provided it really worked. We would need to port
qrexec and gui agents to run inside such VM, but besides that this
should fit well with the architecture.

Finally something we can agree on ;)

In fact, the reason I started looking at the Qubes lists tonight was because it was suggested to me in private communication that I might have solved some problems that Qubes was having, and that there might be synergy potential.  I do not know Qubes well enough to claim I have, but I am open for discussion on the subject.

If anyone has followup-interest, please cc po...@iki.fi

  - antti

[Axon]

On 09/19/13 06:11, Joanna Rutkowska wrote:
> But generally, I would be happy to have such light VMs for running just
> one apps in Qubes OS, provided it really worked. We would need to port
> qrexec and gui agents to run inside such VM, but besides that this
> should fit well with the architecture.
>
> joanna.
>

Instead of *replacing* conventional Xen domUs with app-level
virtualization, what about *combining* the two approaches by preserving
Qubes' current security domain structure and integrating app-level
virtualization *within* security domains? This would allow you to
maintain high-level security domain isolation while also getting the
benefits of fine-grained application-level segregation, but with more
flexibility (e.g., the ability to prioritize performance in doing
app-level virtualization without sacrificing overall security) and
perhaps even more security (due to the nested virtualization).

[coderman]

On Thu, Sep 19, 2013 at 1:57 PM, <antti....@gmail.com> wrote:
> ...

> In fact, the reason I started looking at the Qubes lists tonight was because
> it was suggested to me in private communication that I might have solved
> some problems that Qubes was having, and that there might be synergy
> potential.

i have been using the rump network stacks for experiments in network
stack isolation in userspace. i have also been looking at OSv to
deliver a minimal program and libs into a vm. OSv currently appears
KVM/Qemu focused, but the approach is straightforward to apply to
Qubes HVM instances.

as mentioned above, these are both complimentary techniques and
provide significant memory savings when using many application or task
specific VM instances in a Qubes desktop.

please do inform of any developments, and in turn i hope to have some
public commits in a few weeks once other obligations are complete.

best regards,

[coderman]

On Thu, Sep 19, 2013 at 6:04 PM, Axon <ax...@openmailbox.org> wrote:
> ...

> Instead of *replacing* conventional Xen domUs with app-level virtualization,
> what about *combining* the two approaches by preserving Qubes' current
> security domain structure and integrating app-level virtualization *within*
> security domains?

this is probably the most expedient and pragmatic approach to
isolating certain applications on a per app / per instance basis.

that said, the strength of Qubes strong isolation between domains is
useful to apply at this same per application and per instance
granularity, if you can make it workable.


sad reality tells us some tasks entail their own worlds of operation
with many dependencies and workflows; these are likely to remain
chimera of larger domU environments with some per application
isolation via techniques above, perhaps combined with some explicit or
training/implicit RBAC rulesets, also combined with ... [turtles all
the way down] ... you get the picture.

i am a fan of defense in depth; i will take what works. which is many
things, until more ideal isolation is in place :)


best regards,

[Iestyn Best]

Hi,

I know this is an old post but I think it is becoming more relevant with some of the work happening at the moment.

It would be interesting to see if anyone who replied to this previously has any updates.

Today we seem to have a lot of options with regards to unikernels and library OSs that are no longer just academic.

Please share your thoughts and let us know where your passion is at the moment.

Regards,

Iestyn Best