Feature suggestion: Template Stacking

[monkey]

Hello,

Updating multiple Template-Vms which are minimally different (package
wise) requires downloading the same updates multiple times.
It would be nice to have the ability to base templates on other
templates: E.g one could have a 'Base Template' with the bare
necessaries plus multiple other templates for different AppVm-types like
networking, development etc.

I don't know if this is actually possible, maybe one could use
onion/aufs for the actual stacking, even though resolving dependencies
of installed packages could be tricky.

[Joonas Lehtonen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

> Updating multiple Template-Vms which are minimally different
> (package wise) requires downloading the same updates multiple
> times.

If every templateVM uses the same UpdateVM then downloads will only be
fetched ones by the UpdateVM (firewallVM) and cached on disk, no?

If possible, the feature would still be useful because it would reduce
disk space usage.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTb1gTAAoJEG58zmw5nc+va84P/34DRC8Z9Y/rbcBci3q4AXzc
bbCtf9OWDaWUGiSj0bFy37JNOkcVE/wnZVm9vINGukZKSKj4ZT07n3FYILBkyA7u
rmeV8623Va7UbM+cRjooighMQAEMdPB1PtFz8VmOCjDOq/RC5/d3xDvn4EvWR28I
q1pbBcAA+zoemP2stpqqjmGc+kVyGn8FET7ia+g82gEhEYjcrpaWXfBvQxeCpYCW
OxAGoioE2bFmr/E84Yr5xqxN6km9fP4Opg4KZvKjgXr06kULGZvW5CzXEiPUCi9p
j2Y/ubVN6GBnuE2rx+g6TeHgdPGptfxlk0C4Q/YOrqrJEMKqwMaR2rUVsuAQwzbA
FyqP1qaUvjNPYJi4EfMyJnkv0jV2slZI3zIN3jIz65pjkvyHDw7x4l8Q+9zWlRhx
LXF62TsF/B700wpIKNWw03MqMgul1SEvAZnDeHmiez3lS+P+F0jaG9Ot7Im9tXaM
9kpSPFBuR+SFrCSWsC89IxKdWnveIp+kdg1S1fID2G4N67WtaZ38N6I80bQEkwob
8i4Jqc9TYwe2F1JN398iNDOmLHcxuOHg5UcFWtUjHzWkioI9elzu99D4wPws2CJ+
mTunb0ZfYsrSjvjKZ9aAsEuqyNeEEji3ZhSTCFeHfqXo+iM0PvSnuou10xcq89aF
UvNLkhtEKBvfCjotsgmW
=2fpv
-----END PGP SIGNATURE-----

[monkey]

On 05/11/14 12:59, Joonas Lehtonen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
>> Updating multiple Template-Vms which are minimally different
>> (package wise) requires downloading the same updates multiple
>> times.
>
> If every templateVM uses the same UpdateVM then downloads will only be
> fetched ones by the UpdateVM (firewallVM) and cached on disk, no?

I did not find any Information about this. Could you point me to it?

[Joonas Lehtonen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

> I did not find any Information about this. Could you point me to
> it?

To be honest I haven't found documentation about that myself (I'm new
to Qubes OS as well).

I "know" about that updates procedure just because of using Qubes.

You can see in the default templateVM's Firewall rules, that it has no
network but the "Allow connnections to Updates Proxy" is checked.

In the Qubes Global Settings (in qubes-manager) you can see a config
option "UpdateVM" which is 'firewallVM' by default.

http://qubes-os.org/trac/wiki/Dom0SecureUpdates
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTb2/lAAoJEG58zmw5nc+vDrwP/0u01qK44hbrZWAre/k8zGgm
W/ABZN5+a4DidliB5FyYV7J5P9JxJb43PQq8JkGfbLnNGqVonfghQyfdOTSvKZDA
5/T2HvLivcKIp3B5MulctuXYXZDzB3Z7E5IY/G9+CTLETCnr9GXB4mGCUeQrMyrz
wf35YBWR7mraeWROmxIEhW+LKGnN2eh51mmw6SjaEgw7hNRTfbNOr7VP7YnFDv4M
IBz9iBuST5GLtbvhM5dtgSouGBNvGG422KWvliknRb2hPePbHmvcUYLHMNJf16k9
YhkFjpbBoSyx00OtgnTkJikL92LwfL2pRyKwIjAoKv7NBOcEKTBN1rB8AWmEGj92
RPil4OaUrJcVfx+JzmEbEIu4wTbatvCIgq4Sa0sLGKAIM3AO84NuS88m9JNtPHSk
a2da5lkMxNUvlXHZvQDLM35Jl0hzbemMJjdAxc1epuuWYMa+T+HW3BGlGqOtdGK/
n2kOmvUWgBaJ6a4GQRjzJa8xMz20MyAPazdRk/rkq0F3R8gY0n/V7DBPeLe6k/LB
ufgRvmzu7a4UuZSISw4wvpyGkKvKsBIdTvmL8IZD10fM1xhaxjKL0O2VkkdBUm9o
7Z28BpOPRliv9jlkrIOQpT8rzGeNDgNZnqOspnCYr8+Jlvrr9eqH+zss1oxXMb/f
I77864aMLfmsj/CaY9GI
=4/CY
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

On 11.05.2014 14:41, Joonas Lehtonen wrote:
>> I did not find any Information about this. Could you point me to
>> it?
>
> To be honest I haven't found documentation about that myself (I'm new
> to Qubes OS as well).
>
> I "know" about that updates procedure just because of using Qubes.
>
> You can see in the default templateVM's Firewall rules, that it has no
> network but the "Allow connnections to Updates Proxy" is checked.
>
> In the Qubes Global Settings (in qubes-manager) you can see a config
> option "UpdateVM" which is 'firewallVM' by default.
>
> http://qubes-os.org/trac/wiki/Dom0SecureUpdates

That update proxy is only for filtering the access - allow the access to
package repositories, but block any other HTTP traffic. It doesn't cache
anything currently. But probably it is rather easy to implement such caching.

Regarding stacked templates, it would be rather hard to implement, at least
because of rpmdb, which need to be somehow merged across all the layers in
that case. Also storage architecture would need some major rework - currently
template storage sharing/overlay is based on block device layer, not
filesystem, so not possible to update lower layer without throwing away upper
one (otherwise filesystem metadata will be messed up).

Currently we don't have "template stacking" feature on our roadmap, neither
for R2 nor R3.

--
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?

[Joanna Rutkowska]

On 05/11/14 14:55, Marek Marczykowski-Górecki wrote:
> On 11.05.2014 14:41, Joonas Lehtonen wrote:
>>> I did not find any Information about this. Could you point me to
>>> it?
>>
>> To be honest I haven't found documentation about that myself (I'm new
>> to Qubes OS as well).
>>
>> I "know" about that updates procedure just because of using Qubes.
>>
>> You can see in the default templateVM's Firewall rules, that it has no
>> network but the "Allow connnections to Updates Proxy" is checked.
>>
>> In the Qubes Global Settings (in qubes-manager) you can see a config
>> option "UpdateVM" which is 'firewallVM' by default.
>>
>> http://qubes-os.org/trac/wiki/Dom0SecureUpdates
>
> That update proxy is only for filtering the access - allow the access to
> package repositories, but block any other HTTP traffic. It doesn't cache
> anything currently. But probably it is rather easy to implement such caching.
>
> Regarding stacked templates, it would be rather hard to implement, at least
> because of rpmdb, which need to be somehow merged across all the layers in
> that case. Also storage architecture would need some major rework - currently
> template storage sharing/overlay is based on block device layer, not
> filesystem, so not possible to update lower layer without throwing away upper
> one (otherwise filesystem metadata will be messed up).
>
> Currently we don't have "template stacking" feature on our roadmap, neither
> for R2 nor R3.
>

And I'm not sure we would ever (anytime soon) want to move from a
block-level backend to a filesystem-level backend due to increased
complexity of the latter (read: more prone to exploits). Unless we
migrate to untrusted storage domain, something which has been described
in the original Qubes architecture document, but has never implemented
so far, as it requires lots of non-trivial building blocks in place
(reliable trusted boot, signed-only block device, etc).

We should be careful not to turn Qubes OS into... traditional monolithic
bloated OS! Fat interfaces are enemy of good isolation. Remember that
CPU ring3/0 and MMU isolation has never been subverted for the last few
decades, and yet there are millions of ways to get around the isolation
that today's OSes build on top of those mechanisms. It's because of the
"glue" that has been added on top of them.

joanna.

[Marek Marczykowski-Górecki]

I don't see security problem here - that merging would be done in VM, which
will merge:
1. template filesystem (r/o for VM, r/w for template only)
2. possible another template layer (r/o for VM, r/w for template only)
3. local changes (r/w for VM, not even accessible for template)

VM need to trust its template(s) anyway, so there isn't a problem with
template exploiting VMs. But in another direction, template doesn't even see
its VMs (or upper template layer) filesystem, also VM do not have r/w access
to any template accessible device, so no way to template get exploited by VM.

Note that from dom0 perspective, those are still only block devices.

But still, such filesystem level merging is way more complicated, OS specific,
and we probably don't want to implement it anytime soon.

> Unless we
> migrate to untrusted storage domain, something which has been described
> in the original Qubes architecture document, but has never implemented
> so far, as it requires lots of non-trivial building blocks in place
> (reliable trusted boot, signed-only block device, etc).
>
> We should be careful not to turn Qubes OS into... traditional monolithic
> bloated OS! Fat interfaces are enemy of good isolation. Remember that
> CPU ring3/0 and MMU isolation has never been subverted for the last few
> decades, and yet there are millions of ways to get around the isolation
> that today's OSes build on top of those mechanisms. It's because of the
> "glue" that has been added on top of them.
>
> joanna.
>

[Joanna Rutkowska]

Ah, good point indeed. So, assuming we could have "stackable"
composition of a filesystem for the VM, what other potential problems we
need to solve, apart for rpmdb? What about /etc?

joanna.

[Marek Marczykowski-Górecki]

Merging filesystems like aufs handle this just right - files changed in upper
layer will hover that files in lower layer. The only problem is where file
need to have content somehow merged. IMO this isn't the case for most /etc
files (perhaps only passwd/group for package-specific users).

Note that rpmdb isn't only technical problem because of this merging, also
package dependencies will be problematic. Imaging we have installed package X
in upper template layer. This package requires package Y in version 3. Then we
upgrade lower layer template, which upgrades package Y to version 4. Now we
have broken dependency in upper template layer (probably only until upgrading
also upper template layer, but still).

[bradbury9]

Sorry if it is a dumb question but...

Would it not provide 'child' template access to sensitive data from 'parent' template? Yes, read only, but still sensitive.

Guess it is fine with usual templates, but maybe adding a warning asking for a user confirm would be wise. Something like 'Are you sure? This action will give the createdTemplateVM readonly access to the parentTemplateVM'

[Axon]

bradbury9:

> Sorry if it is a dumb question but...
>
> Would it not provide 'child' template access to sensitive data from
> 'parent' template? Yes, read only, but still sensitive.
>
> Guess it is fine with usual templates, but maybe adding a warning asking
> for a user confirm would be wise. Something like 'Are you sure? This action
> will give the createdTemplateVM readonly access to the parentTemplateVM'
>

But TemplateVMs shouldn't contain any user data in the first place.
(That's what AppVMs are for.)

A list of installed packages could be used for fingerprinting a TorVM
user, but that seems easy to deal with here, since a parent template
will by its very nature contain only a proper subset of the installed
packages of its child(ren). (So, you could just make sure that all of
your AnonVMs are based on immediate children of the default template, if
not based on the default template itself.)