Figure out how to allow yum updates for fedora repos without allowing */http on the firewall

[joanna]

... and then make this a default f/w rule for the default template.

[marmarek]

This isn't easy, because yum dynamically select used mirror (from downloaded mirror list file AKA metalink). We can force yum to use specific mirror (or master server), but this will be much inefficient way (eg downloading from another continent at speed about 10kbps...).

Maybe the easier way will be enabling */http only for time of doing update?

[joanna]

Is it possible to download current list of mirrors from fedoraproject.org easily? If so, we could, enable http only to those IPs?

Additionally we could use VM-side code to allow this http (optionally http to mirror list) only for yum process?

Finally, if implementing any of the above (or both) we should figure out how to do that in most generic form. Surely the firewallvm would need to treat template/updateable VMs specially. But note that other standalone and template VMs (i.e. other than standard template) will likely also be getting updates from other repos... Perhaps we could introduce a special firewall rule -- 'fedoraproject.org updates' (if we implamented option #1 above with dynamically configured host list), or 'yum updates' (the temporary access to */http for yum process only for the time the user triggered an update). The latter assumes that the user always triggers the update via manager button, so that we could let the firewallvm know that http should be now allowed, so it won't work for a saavy user starting yum update from VM's terminal. But that's perhaps acceptable.

[marmarek]

Even if it is possible to download full mirror list (​http://mirrors.fedoraproject.org/publiclist), it is changing dynamically, so must be updated often. Look also on #575 - this is another repo with own server and maybe also mirror list. IMHO basing here on IP list isn't as generic as we need (note that the same problem will arise with Windows).

Anyway user shouldn't start any application in (any) template but update, so the only real problem are standalone VMs.
It is possible to apply different firewall rules for yum process using network namespaces (​https://eos.aristanetworks.com/2011/06/linux-namespaces-at-arista/), but it seems to be complex (involves creating virtual network interface etc). There is also possible to apply some firewall rules based on UID of process (owner iptables extension), which is much easier and still provide some level of protection of user actions (allow */http only to root-owned processes).

Hmm... some crazy idea: perhaps we can run some light http proxy in netvm, which will filter traffic to only allow access to yum repos (based on path regexp - rpm files and yum metadata). Then we can configure yum to use this proxy and configure in firewall which VM will have access to this proxy, instead of large, dynamic list of IPs.
This will introduce some additional service in netvm (we have ntpd already), shared across VMs connected to it, but it should be accessible only to VMs, not outside world. Currently yum in out template connects to even more untrusted (possibly spoofed) servers than local proxy, so compromise of this proxy isn't worse than current setup.

[joanna]

I like the idea of using an http proxy -- it should perhaps also speed up the updates download process when we have more than one template/standalone vms that use the same repo (which is often the case). The only problem seems to be increasing an attack surface on netvm. While netvm itself is not much of a problem, it makes it simpler for a 2-stage attacks, i.e. an attacker first compromises a netvm (from the least trusted templatevm/standalonevm) and then, from the netvm, attacks one of the more trusted templatevm/standalonevm, e.g. exploiting a hypothetical bug in yum client.

Perhaps we could use a mechanism similar to the one we use for dom0 updates -- i.e. to have a special updatevm, that does all the yum downloading, and later shares them with interested VMs over qrexec. But then again, one of the least trusted of the updateable VMs might trick this updatevm to connect to a yum server that is malicious and tries to compromise yum in this updatevm, so I think this is equivalent to having an http proxy for yum, as you described.

[marmarek]

​http://git.qubes-os.org/gitweb/?p=marmarek/core.git;a=commit;h=96508abf2ce50a7e3b7f949f0014532969c35110
​http://git.qubes-os.org/gitweb/?p=marmarek/core.git;a=commit;h=4bac57818ea5c80a02de3d3ae2a6746de09c0e6e
​http://git.qubes-os.org/gitweb/?p=marmarek/core.git;a=commit;h=2ca4b11183a8f41dda5e52ffb627222f17118704