-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2016-08-12 15:31, johnyju...@sigaint.org wrote: > Greetings, Qubers. > > 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. > As I understand it, this creates rules in sys-firewall to enforce that > policy, and allow forwards to the tinyproxy living in sys-net on port > 8082. > > -A FORWARD -s 10.137.2.25/32 -d 10.137.255.254/32 -p tcp -m tcp --dport > 8082 -j ACCEPT -A FORWARD -s 10.137.2.25/32 -j REJECT --reject-with > icmp-host-prohibited > > Good 'nuff. > > However, there is nothing stopping such an AppVM (say, for example, it were > compromised) to making any connections it wants through that > 10.137.255.254:8082 proxy, to call home, download malware, whatever. (So > my otherwise properly-configured "Banking Only" vm, that is configured to > only allow connectons to my bank, can actually contact that hacker site in > russia if some bad javascript or other compromise happened.) > > I set such a VM, networking disabled or restricted to one or two sites, no > ICMP, no DNS, but updates allowed, and pointed Iceweasel's proxy to > 10.137.255.254:8082 and was able to browse to my heart's content, even > totally bypassing sys-firewall, so it was potentially even *more* open than > if "allow network access except" were checked. > > This seems like a bit of a potential security risk. > Indeed, this is why the box is unchecked in AppVMs by default. :) > In general, I would recommend that updates *only* be allowed for Template > VM's. I don't think this would be a good idea. There are many times when it's important to be able to update or install a package in an AppVM even though it won't persist after restarting that AppVM (to check compatibility, for temporary use, etc.). > And even then a compromised template can call home freely during the > (hopefully brief) time it's running. Well, yes, but if a TemplateVM is compromised, then it can potentially phone home even if you remove its NetVM, due to the existence of cooperative covert channels. > (Also, I would generally recommend turning off all other Networking for a > Template, unless you do need some non-update network configuration for an > app, such as adding a browser plugin; but that should generally be rare.) > Indeed, this is why the default setting in TemplateVMs is to allow access only to the updates proxy. > (Also, Temporary OS updates are indeed handy in the AppVM's for testing or > one-off app runs, but leaving this checkbox on is just like turning > networking full-on for the AppVM. The user should at least be aware of > this fact. I wasn't.) > > At the very least, the GUI should educate the user about this fact, and > maybe pop up a warning/confirmation page if the user tries to enable update > access for an AppVM. > In principle, I think this is a good idea. In practice, however, there are already so many more accessible ways for users to shoot themselves in the feet, e.g., running programs in dom0 or TemplateVMs (except for intentional initial configuration). Ideally, we'd have such warnings in *all* of those cases. While this would qualify as one of those cases, it seems a bit less dire and bit less likely to affect huge swaths of new users (especially given the defaults). If that's right, then it might be better to prioritize our warning implementation efforts on the most blatant and serious pitfalls first. > While it's easy to work around by leaving that option off except on > Templates, it's a simple way for new users to unwittingly leave an AppVM > wide open. I'm thinking the update server access process might need to be > re-considered a bit. > > I also think more visibility of the overall firewall setup/layout and > potential packet paths (as well as actual traffic) needs to be done > somehow. Perhaps sys-firewall needs something more akin to Shorewall. > (Checking for leaks, and running iptraf in sys-net was rather depressing; > more on that in another post.) > I think that might fall under this: https://github.com/QubesOS/qubes-issues/issues/2135 (I've added a link to this thread in my comment on that issue.) > Thoughts? > > (I worry a bit that the attitude of the Qubes developers is "oh well, if > you're compromised, you're screwed anyway, no sense adding more security." > See no-password sudo, for example. I think the idea is more like: "Let's not bullshit our users. If some purported security measure doesn't actually add any real security, then we're not going to implement (or preserve) it and point to it as evidence of defense in depth (because it's really not). By contrast, we welcome defense in depth that actually works." > I disagree with that approach, and think any reasonable and clean security > measures that could be added, should be added. If you completely give up > on the machine to one level of compromise, you might as well write your > sensitive documents with rock on cave walls, deep underground, lit by > torchlight. Although the way I've been aggressively hacked for years, it > might just come to that :P "Pass the red berries, I need to highlight a > sentence.") > > By the way, I intend all my comments as constructive or for discussion. > It's an awesome system, kudos to Joanna and the team. It's been my main > platform for a couple of weeks now, and I'm loving it, despite a few > glitches and some confusing bits. I hope to be able to contribute > something back to the process. > > (Is that Debian Template manager a paid position? :) ) > I think that depends on the current funding situation (CCing Michael). - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXrslLAAoJENtN07w5UDAwV2cP/jWZVNsbganFUNCNO55NadD9 Axf6ZnFdhNNjAaf9ZuVk3L6eld6dHXz9I4fnXq2U55pxqiBkIJh5UyHjbF/XE8Bb Ijl8Hd/zcNdL94xAjQkUShqPENaY85fVe096qPNlbaFbkYIiz/9CzZeZsUSjWEzA p5PUnMiU07J2u6W9JmxB3pP7m3MGYqnLSd8xUzNGktyS7KARD32pGxlvI1xus973 hGM+L/zF9Ip5b9BInRPLEgw9/F/S3m+RQWag2E3/3L+uaiUNdh1T4wekewXNr0yq lWPKyNzb9lrZ25RFhp4R+rcYAos149bk8ACYPSPQJSP9YGngeEKFBv2PvijDAJ5R GOkorCISKBYouuIsQlHiyI/Ij8WFHXi33u/UanFH/JTwfL5bQ+3WoCNpEDun3U8S 5BZqZUsoCs4F3yiAwpUJFkUd15sUEpmnx43c1EdlrGPA1rZ0svg9aVUEGRU9Hup/ L/Op2He3IUQeSW82NjzFtJ4ZHEBPp60bDmJC0/i20mnKWKJnvFiuOgMWHLDetvZ3 gciKRj8KtsuaEqWaYad44X6Aq2zoQyb7mf7G8LCiJ2Y/Bi8BMP0kyAZbs5PE5eBU 8ypQsIzy642BiIkhx53fJKvGyqAfTgh8q9WU+w3aShYH5UX9vRiFW9itd3TnnLe9 DqyWknsWpVYbt8In3K1A =/w0H -----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/15b2533b-86f8-8fe4-e8af-a72779cb1542%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
