Multiple DispVMs (was: Re: [qubes-users] qvm-open-in-dvm fails EmailVM use case)

[Joanna Rutkowska]

Moving to qubes-devel, please respond there.

On 05/31/14 01:56, Axon wrote:
> Joonas Lehtonen:
>>> >> Problem: Since the DispVM has inherited the firewall rules of
>>> >> EmailVM, the DispVM cannot resolve URLs, thereby defeating User's
>>> >> intention.
>> >
>> > Well it depends :) If I - the user - setup a firewall rule that allows
>> > emailVM only connections to $mailserver, then it would be against my
>> > intention if emailVM could reach arbitrary http server on the internet
>> > via a dispvm.
>> >
> Not necessarily. I (the user) may not want EmailVM connecting to
> anything except my mail server (e.g., because I want to prevent malware
> from infecting EmailVM). Nonetheless, I may want to be able to open all
> links and attachments received in the emails in EmailVM. Since opening
> such links and attachments in EmailVM itself greatly increases the risk
> of infection, I may wish all such links and attachments to be opened in
> DispVM(s).

/.../

Etc, etc.

I think we will all agree that "one DispVM is not enough for everybody"
and that we really need more flexibility...

If we think about why people might want to create a DispVM there are two
primary reasons I think:

1) Because it always comes up clean (no persistent home dir, more
technically no /rw mounted).

2) Because it starts up quickly (which is possible because the VM is
restored from the previously saved "savefile" which is kept in /dev/shm,
which means we don't need to boot a Linux OS, but only restore it from
"suspend", kind of).

There is no reason why we should not be able to support #1 for regular
AppVMs, I think (in that case their "regularity" would mean: VMs which
user can configure by choosing their template, netvm, firewall, etc).
This could be settable via qvm-prefs, so that we could do e.g.:

qvm-prefs anonvm -s disposable true
qvm-prefs anonvm -s netvm torvm

Some other "DispVM" could be prepared for as a convenient document viewer:

qvm-prefs docviewer -s template fedora-20-office
qvm-prefs docviewer -s disposable true
qvm-prefs docviewer -s netvm none

So, whenever Qubes is to start an AppVM which has "disposable" property
set, it will: 1) not mount the /rw for it, and 2) give it a name:
${basename}-{$uid}

We still might have a default dispvm in the system, of course -- this
would be based on the default template and using default netvm and
default f/w settings.

The policies could then be defined like this:

work docviewer allow
anonvm $anyvm deny

The reason #2 given above (quick start from savefile) is somehow
orthogonal to the property discussed in #1 -- I think we can use it even
for normal AppVMs, just make sure we generate the savefile without /rw
and then mount it after the VM wakes up after restore.

In some other scenarios, we might not want to, or not be able to, use
savefile restoration even for the VMs with "disposable" flag (e.g.
Windows AppVMs).

The above change should allow for more flexible and powerful
configurations, satisfying various users who often have varying
expectations as witnessed in the original thread.

I wouldn't even be entirely against introduction of the "disposable"
flag before R2, if that is really so simple as I think :) Marek, what's
your take on this?

joanna.

[Alex Dubois]

Hi,

I have not followed the list for some time (snowed under), so hi again :-) and please accept my apologies if I say something off-topic or impossible to do...
I would prefer a template, an AppVM that mount /rw in rw mode and then a DispVM(s) based on the AppVM mounting /rw but ReadOnly
It would allows easy config of class of DispVM(s) by configuring the AppVM start-up scripts in /rw

Hope it is understandable. This is good as it saves disk space. It is also good if you want to set-up a server that zap back after reboot (ie proxy, apache, etc...)
You have the binaries in the template, the config (and files ie apache web server) in the AppVM and the running config in the DispVM

Hope it helps,
Alex

And Bravo to the team it is getting really great.

[Marek Marczykowski-Górecki]

I'm against changing semantic of "start" operation based on some property. You
basically want that if VM has disposable=true, then VM start really does:
1. Clone the VM to "${basename}-{$uid}"
2. Start that cloned one

So you mean here that setting disposable=true makes that VM a _template_ for
new "DispVMs"? If implementing it this way (but see below for alternatives), I
think it should be rather separate VM type, not a simple property. Otherwise
you'll need to worry about many problems like "what happens when TemplateVM
have disposable=true" or so.

On the other hand it might have sense to have disposable=true for NetVM. But
if that property changes the VM to DispVM template which is only used to
create new DispVMs - differently named, it will be rather problematic to
reference that VM from other places.

Technically /rw of DispVM template VM (fedora-20-x64-dvm) exists. Savefile
preparation looks like this:
1. The VM is started normally, with /rw mounted (but not as /home)
2. If /rw/home/user/.qubes-dispvm-customized exists, /rw/home is used as
template for /home
3. dispvm-prerun script is called (which starts some common apps for a moment
to warm caches, create config files etc).
4. /rw is unmounted, device detached
5. VM state is saved

So for such new DispVMs you'll need two start modes:
1. Normal start for VM configuration (customization of files in /rw/home)
2. Start new DispVM based on such template

Perhaps we could create new tool qvm-start-dvm, which will create new DispVM
based on selected VM (using above procedure, with savefile or not). Then
create new RPC policy action/dstvm keyword ("$dispvm:docviewer"?) to use this
mechanism.

> We still might have a default dispvm in the system, of course -- this
> would be based on the default template and using default netvm and
> default f/w settings.
>
> The policies could then be defined like this:
>
> work docviewer allow
> anonvm $anyvm deny
>
> The reason #2 given above (quick start from savefile) is somehow
> orthogonal to the property discussed in #1 -- I think we can use it even
> for normal AppVMs, just make sure we generate the savefile without /rw
> and then mount it after the VM wakes up after restore.

Except that xen/kernel support for that is often broken... Infamous 4GB memory
limit, single vCPU, or recent balloon driver problems at least.

> In some other scenarios, we might not want to, or not be able to, use
> savefile restoration even for the VMs with "disposable" flag (e.g.
> Windows AppVMs).
>
> The above change should allow for more flexible and powerful
> configurations, satisfying various users who often have varying
> expectations as witnessed in the original thread.
>
> I wouldn't even be entirely against introduction of the "disposable"
> flag before R2, if that is really so simple as I think :) Marek, what's
> your take on this?

I'm strongly against introducing any new feature before R2 release. We are at
release candidate stage, we should fix current bugs and release final R2 (or
rc2). Otherwise final R2 will never happen...

--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[france...@gmail.com]

I'm glad the problem has already been evaluated, and is scheduled for solution, as this is one of my main concerns at the moment.
However, maybe the perspective I finally came up with can help further the discussion.

What if all VMs had the same options regular programs have -that is, we would have "shutdown saving changes", and "shutdown discarding changes"?
In this model, every VM would be cloned on launch; then, the user woud have any moment (and on shutdown) the option to permanently "save" its state (by overwriting the original image) -or never do it, and therefore easily discard any potentially harmful (or just unnecessary) modification.

If this was the idea, I would leave a different sort of choice upon creation: to leave the cloned image on the disk as usual, or to run completely in memory in order to avoid forensic detention -which I remember was another proposed enhancement to the DispVM system. The second mode would still allow to save the final state anyway, if the user should wish; for instance for initial configuration.

This would just be perfect for the way I personally use Qubes, and seems the simplest... of course, I can't judge how easy it woul actually be from a developer's perspective, but maybe it actually works.

Hope my idea can be useful,
     Francesco Dondi

[Marek Marczykowski-Górecki]

On Thu, Nov 06, 2014 at 01:25:47PM -0800, france...@gmail.com wrote:
> What if all VMs had the same options regular programs have -that is, we
> would have "shutdown saving changes", and "shutdown discarding changes"?
> In this model, every VM would be cloned on launch; then, the user woud have
> any moment (and on shutdown) the option to permanently "save" its state (by
> overwriting the original image) -or never do it, and therefore easily
> discard any potentially harmful (or just unnecessary) modification.
>
> If this was the idea, I would leave a different sort of choice upon
> creation: to leave the cloned image on the disk as usual, or to run
> completely in memory in order to avoid forensic detention -which I remember
> was another proposed enhancement to the DispVM system. The second mode
> would still allow to save the final state anyway, if the user should wish;
> for instance for initial configuration.
>
> This would just be perfect for the way I personally use Qubes, and seems
> the simplest... of course, I can't judge how easy it woul actually be from
> a developer's perspective, but maybe it actually works.

There are some disadvantages of such solution:
1. Much bigger disk usage (multiple copies of a whole VM filesystem)
2. Increased VM startup time (that clone operation) - this could be done
in some smart way to mitigate this problem, but still there will be some
performance cost
3. Most important - you'll loose main feature of the templates (for
those with "saved changes) - central updates, so you'll need to install
updates separately in each such VM.

[Francesco Dondi]

No, in my idea we wouldn't necessarily duplicate the whole filesystem, non-standalone VMs would still take the root read-only from a centrally updated template.

Right now I have a personal and personal-template VM. They are both AppVMs, so they weight very little. When I want to make a permanent change to my personal storage (like installing a Firefox add-on), I power down 'personal', destroy it, fire up 'personal-template', apply the change there, power it down, clone it, and change the name of the clone to just 'personal'; finally I power that on again.
So it can be done without changes, and it only doubles the personal storage. I just think it could be automated to save a great deal of clicks, and probably also of time.

Now that I think of it, I could probably automate it right away with a bash script. Still it would be much more seamless, and possibly efficient, if backed into the os from the start.

Francesco Dondi

[Alex Dubois]

+1 from me to get something like this available.

I would prefer a second partition, /ro that can be made read-write (when modification is required) and have the normal /rw be a copy on write of /ro that get discarded only in case of disposable VM

Francesco Dondi

--
You received this message because you are subscribed to the Google Groups "qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
Visit this group at http://groups.google.com/group/qubes-devel.
For more options, visit https://groups.google.com/d/optout.