-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sat, Aug 13, 2016 at 10:54:22AM -0700, Andrew David Wong wrote: > On 2016-08-13 09:49, johnyju...@sigaint.org wrote: > >>> Say you have a VM (e.g. "Banking only"), which has a NetVM of > >>> sys-firewall, but for which you have disallowed or greatly restricted > >>> networking, turned off DNS and ICMP, but left on "allow connection to > >>> updates proxy." > >>> > >> > >> That box should be unchecked by default in AppVMs and checked by default > >> in TemplateVMs. > > > > Fair enough. Choosing a sane default is half the battle, and does > > indicate to the user (subtly ;) ) the right thing to do. And I agree you > > don't want to "warn the user to death" about every possible peril. > > > > Perhaps a good compromise (i.e., a less intrusive way to warn/educate the user > about this) would be with an explanatory tooltip. Added the suggestion here: > > https://github.com/QubesOS/qubes-issues/issues/2211#issuecomment-239632572 > > > One argument I might make, however, is that the update proxy does not > > belong in the sys-net VM, but in the sys-firewall VM. > > > > Part of the elegance of the sys-net VM is that it isolates the network > > card from shenanigans affecting other parts of the system. Compromising > > the update proxy could obviously hand over the "keys to the kingdom" to > > all the VM's via template updates. (Although proper package signing and > > verification would limit that threat.) > > > > Part of the Qubes philosophy is "Don't trust the infrastructure," where "the > infrastructure" includes the updates servers. We basically assume those are > compromised and instead place our trust in package signature verification. > From this perspective, it isn't handing over the keys to the kingdom at all, > and proper package signing and verification does more than just limit the > threat. It guarantees -- to the extent that cryptographic signatures can -- > that the package we've received (even from a possibly compromised server) is > in fact the package the signer intended for us to receive.
Exactly. Also note that the updates proxy is in fact a simple http proxy, so all it can do, can also be done by any other component in the network path between template and updates repository itself. This includes anything running in sys-net (even if updates proxy is running elsewhere). > > And yes, if the network card is compromised, even moving the update proxy > > to vm-firewall isn't going to protect you from mitm, redirection, DNS > > spoofing, and other attacks from sys-network. > > > > However, it does make more sense with yet-another suggestion I might make: > > > > Since tinyproxy should only be used to contact legit update repos, there's > > no reason it couldn't be configured (perhaps auto-configured by Qubes > > Manager, from information in each template), to restrict access to *only* > > update sites on port 443 (last part is already there). e.g.: > > > > tinyproxy-updates.conf: > >> FilterDefaultDeny YES Filter tinyproxy-updates-filter.conf > > > > tinyproxy-updates-filter.conf: > >> fedoraproject.org debian.net debian.org [windows URL for those crazy > >> enough to run windows hvms...] > > > > I'll be manually doing this myself, shortly. > > > > I'll also try moving the update proxy to sys-firewall (just a matter of > > setting it up there, and changing the Templates to have their dns/apt > > tools to point to it, I think)... Where does the Qubes VM Manager get its > > proxy-address to modify the firewall rules? Hopefully from some xml > > template I can change. In fact if you start updates proxy in sys-firewall, it will be enough - it will intercept traffic going to the proxy. Details: https://www.qubes-os.org/doc/software-update-vm/#tocAnchor-1-1-9 > > With what I would now consider an important configuration file now part of > > tinyproxy, it makes a bit more sense to get it out of sys-net, so a > > compromised sys-net can't affect which servers the Template (or > > mis-configured App) VM's are allowed to contact (although yes, it could > > still redirect packets, yadda, yada, yadda...) There is very little point in this. There is so much infrastructure involved in updates distribution (all the mirrors etc), that assuming none of it can be compromised is unrealistic. On the other hand, even compromised mirror can't do anything about properly signed package (besides hiding its existence). Updates proxy is only to prevent user mistakes - like browsing the web directly from the template. Its power comes not from filtering the traffic, but from the fact that any application not explicitly configured to use the proxy, will not be able to access the network. By default only package managers are configured to use the proxy. - -- 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? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXr4P7AAoJENuP0xzK19csNqcH/1Fk/ZamkPmj4vA8cgdr7q/I eidMIFnl8icmKEzdggOpMIjbLtdqTXfWkrea0R5+oF+qrvBzN+1P80rL6BVlNAeP mb3YI0Fo2p+ZnNI3zsbx6aDo4DWBFbLmUcVzznHggHOfplfNJiA1agy8tMI1C92P JLgZ7xepn8SIvTEoLJoI1lFEjOQPwGvrbohQUa3Wk5IuE7C7H8LVooVcJLnfX5Ne Fl71nhyjxjt3lu9IYNkDd4B79JBc+SaazOObUIHEXfgcKeqBHYzC8bCGPGxzfWYa aoXo9KTvjjDn9/i1Z22wk1Op0OFYz+tDY/l7HXQsFTxLc+crAuQCkX0K+pNEG+A= =zimK -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20160813203258.GM5701%40mail-itl. For more options, visit https://groups.google.com/d/optout.
