Re: [qubes-users] Virtualization in the cloud
I'm of the opinion that if "everybody's doing it" then it's probably best to take a different approach;. I don't trust or play around with the cloud, especially with a behemoth like Google. Color me paranoid. Sent with [ProtonMail](https://protonmail.com) Secure Email. Original Message Subject: [qubes-users] Virtualization in the cloud Local Time: June 17, 2017 2:04 PM UTC Time: June 17, 2017 2:04 PM From: iamrootyr...@gmail.com To: qubes-users I was just wondering. Is it possible to get a VM on Google Cloud Compute (for e.g.) and be able to mitigate the security issues caused by not being the owner of the metal/hypervisor. If, say, you run an https enabled apache instance, the ease of creation/setup, ability to later scale and redundancy are all nice. But Google have access to your ssl key contained within the virtual drive. You could use LUKS with full system encryption but I"m not sure this helps. They could snapshot a running instance (post LUKS pw challenge) and respin the VM in that state. They could also modify the hypervisor to add a keylogger to the virtualised keyboard input interface to capture the LUKS password. They could also simply lift the key from the VM"s RAM (Evil Maid in the cloud?). So the real question is .. could Qubes run in an AWS/Azure/Google instance and it"s assumptions of everything being permanently comprimised withstand even the hypervisor being untrustworthy? Or do you have to ultimately not only trust the hypervisor but also be the owner of it and the hardware? Is there ANY way to maintain security in the cloud or if you care about security should you simply avoid cloud-hosting altogether and do it in-house? Lots of people seem to do it, maybe they"ve just accepted the risk. -- 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/8f94ba97-cc72-44d6-a065-7171b707e00a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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/_kHSBQKb9x7PnAuVK7BuZVO8vlu_bQgiRNo14axMllsIVcLAANsw8aVPj9_09CDiNPfAaS0BrxdkhJ0fqVjWb7Bo9Y6v1betHghk-U8ydJo%3D%40protonmail.ch. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Question(s) regarding Qubes minimal templates
> I'm a strong advocate of using minimal (or smaller) templates, customised for > specific use cases. Some people HATE this approach. > > unman Really? Coming from the sort of people with the patience for an OS like Qubes? I'd think anyone who's involved enough to have an opinion would be in favor of that -- that's kind of the idea here, isn't it? One thing I wish I could change would be the visual clutter it produces; anybody know of a means to flag these VMs as internal so I can hide the ones I'm not interested in seeing regularly? That being said, I'm definitely in agreement with you, unman. Would you recommend any particular setup for a more granular approach? My current arrangement of VMs [work in progress; suggestions welcome!] is structured like this as of now: - dom0 - fedora-24 - dispVM(s) - fedora-24-minimal ( ... > derivative templates > appVM > packages*) - fedora-24-min-net - sys-net** - General-purpose: gnome-keyring, less, man, pciutils, psmisc, sudo, vim-minimal, xterm - Template-specific: dbus-x11, dejavu-sans-fonts, NetworkManager, NetworkManager-wifi, network-manager-applet, notification-daemon, tinyproxy - fedora-24-min-frwll - sys-firewall - No additional packages; effectively a clone of the Fedora-24-minimal template. - fedora-24-min-vpn - sys-vpn - G.P.: sudo, xterm - T.S.: [TBD; trying out some different VPNs atm] - fedora-24-min-usb - sys-usb - G.P.: sudo, xterm - T.S.: qubes-input-proxy-sender - fedora-24-min-pen - pentest - G.P.: sudo, xterm - T.S.: aircrack-ng, ettercap, kismet, nmap, nmap-telcat, tcpdump, wireshark***, [remaining packages TBD] * The concomitant dependencies aren't included in these lists (n.b. packages are installed in the respective templateVM) ** Can't quite get this one to run properly yet; I presume I need to install a proprietary driver in the template to make this work for my machine(?) *** Very interested in trying out v6ak's split-wireshark" idea but haven't found the time yet. Thanks for sharing that idea, v6ak! - TN Sent with [ProtonMail](https://protonmail.com) Secure Email. -- 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/QOUCXs5Owf4_vFzLV8tj0-YlBHu981vPYZYllxyjhEEUARUYol1xXRAHwNTExkDU0O9iMVo0_fWuy4AlV4-AlAT_GSEpbXPcDbfw6jw_GYw%3D%40protonmail.ch. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Question(s) regarding Qubes minimal templates
Hey all, Thanks in advance to those kind enough to entertain these questions! - Given that more installed applications generally create a larger attack surface, why aren't the minimal templates set as the default templates for sensitive VMs such as the SysVMs? - Is this just a matter of convenience and/or usability? - Presuming this is planned for future releases, are there any particular changes or precautions that should be made/taken by those who opt to use a 'raw' minimal template as their TemplateVM for the aforementioned VMs? - Are there any significant protections afforded by the full-featured VM images that are absent in the appropriately configured minimal VMs [going by the current Qubes documentation]? Any pitfalls exposed by the latter? Best, TN Sent with [ProtonMail](https://protonmail.com) Secure Email. -- 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/3FF2R8eHmwUOr3F2_ueuFAG9XRtJWBiID0s-mGm9cYSpKZk4pODF9YCujs_VonqdA-hdX1-2JqGWP73C3dexm9rc95CwuBlLtHCamQUkKr0%3D%40protonmail.ch. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] How to stop sys-whonix and sys-firewall from starting on boot?
Would this require a CLI command to disable or is this possible through Qubes Manager? I've noticed that whenever I deselect the "Start VM automatically on boot" option in the QM settings area [for sys-net and sys-firewall specifically] they still continue to boot up at system startup. Best, TN Sent with [ProtonMail](https://protonmail.com) Secure Email. Original Message Subject: Re: [qubes-users] How to stop sys-whonix and sys-firewall from starting on boot? Local Time: June 7, 2017 10:35 PM UTC Time: June 7, 2017 10:35 PM From: un...@thirdeyesecurity.org To: mari...@grrlz.net qubes-users@googlegroups.com On Wed, Jun 07, 2017 at 08:24:36PM +, mari...@grrlz.net wrote: > I have already disabled that option on the VM's settings and I have also > disabled automatic updates on Qubes Manager general settings but nothing > changed. > Any ideas? If you have any other qubes set to start automatically, then the upstream qubes will be started too. The default netvm is started automatically - you can stop this by disabling the qubes-netvm service in dom0. unman -- 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/20170607223539.GE5307%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout. -- 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/e6N6eQ_87HTlq-5m3O1wPgBZn9qMVujHXuASz7IOcxgyktvRD8vfIaU0nDexeUB7maGYzDPTrcC2fkwmVL2QIq0Ttwib0LsOEUOjdS6GqAo%3D%40protonmail.ch. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] "Restricted" applications launchable from AppVM via terminal?
Thank you for the quick answer, unman! I appreciate the added clarity. Sent with [ProtonMail](https://protonmail.com) Secure Email. Original Message Subject: Re: [qubes-users] "Restricted" applications launchable from AppVM via terminal? Local Time: June 7, 2017 10:39 PM UTC Time: June 7, 2017 10:39 PM From: un...@thirdeyesecurity.org To: Tomei Ningen qubes-users On Wed, Jun 07, 2017 at 06:14:03PM -0400, 'Tomei Ningen' via qubes-users wrote: > Hi all, > > I'm not sure whether anyone else has noticed this, if this is a feature/bug, > or if I'm simply misunderstanding what should be occuring, but I noticed that > despite ostensibly restricting applications from running within a given VM > via Qubes Manager by curating the "Selected" application list (VM settings > > applications > 'Available' / 'Selected'), I'm still able to launch whatever > arbitrary application from the command line. Is this intentional? > > Best, > TN > That's just a simple way of adjusting the applications that appear in the Menu for that qube. It's not a way of restricting what applications can be run in the qube. -- 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/D52X0pjB-b7-a5sf9VPqVsm9YVVbrojWn43TbLmveaoYuTV3uAYE4ZH00AYzMTmL8-rrJymWW1zl3Vfcqgip2iDClZ8CIyRK7PnB59y0BKo%3D%40protonmail.ch. For more options, visit https://groups.google.com/d/optout.
[qubes-users] "Restricted" applications launchable from AppVM via terminal?
Hi all, I'm not sure whether anyone else has noticed this, if this is a feature/bug, or if I'm simply misunderstanding what should be occuring, but I noticed that despite ostensibly restricting applications from running within a given VM via Qubes Manager by curating the "Selected" application list (VM settings > applications > 'Available' / 'Selected'), I'm still able to launch whatever arbitrary application from the command line. Is this intentional? Best, TN Sent with [ProtonMail](https://protonmail.com) Secure Email. -- 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/SdiNC9lWymfNDuYJumFOmHgbb8p74CWAZMbvyCB6rhyaTLxtq6T7Xah8SPQuIC90iB1lKSmGTNQ8cu9vfzM8DpVYhJfAu6oZoNmz6eo0lMg%3D%40protonmail.ch. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes Canary #12
This is an interesting point to consider, thanks 7v5w[...]. Some thoughts this brings to mind: - I know that we all understand that the canary system is little more than a matter of reassurance - as I understand it, it's not a security feature so much as a security blanket. That said, I would imagine that avoiding the chilling effect which often accompanies undue paranoia is a practical priority and I also feel that the community would be better served if the frequency was increased rather than decreased. As has been said, should the worst occur we'd be better equipped to mitigate damages and/or minimize exposure. - I wonder if the debate over whether there's a 'better' time to update the system with respect to the canary schedule is a moot point. I would think that the risk of having unpatched vulnerabilities would greatly outweigh the ostensible benefit(s) that might be afforded to those intent on avoiding a TAO-type situation, no? Regardless of the threat model you subscribe to there are tons of players on the field and most will take the path of least resistance if it should be available to them. To that end, if the worst were to occur would any of us actually trust a backup to be trustworthy? We know now that many of the methods of evading detection and achieving persistence are sophisticated and disturbingly effective. I'd consider it Game Over at that point. - Why aren't the canaries date-specific? I'm sure this is done with good reason but I'm curious to know what that reasoning is. - TN Original Message Subject: Re: [qubes-users] Qubes Canary #12 Local Time: June 5, 2017 5:35 PM UTC Time: June 5, 2017 5:35 PM From: 7v5w7go9u...@gmail.com To: qubes-users@googlegroups.com On 06/05/2017 04:06 PM, Unman wrote: > On Mon, Jun 05, 2017 at 03:59:26PM +, 7v5w7go9ub0o wrote: >> On 06/05/2017 01:42 PM, Andrew David Wong wrote: >> >> >> >>> 1. The date of issue of this canary is June 2, 2017. >> >> >>> 5. We plan to publish the next of these canary statements in the first >>> two weeks of September 2017. Special note should be taken if no new canary >>> is published by that time or if the list of statements changes without >>> plausible explanation. >> >> >> >> Thanks for the note. >> >> IIUC, the canary system is now quarterly and three months until the next >> canary. That also means that a back-door and gag order could be placed >> into effect against Qubes today, and users would be clueless about it >> 'til September - up to three months of user jeopardy if there are Summer >> updates. >> >> The cautious user will reason that his system updates should be only >> applied immediately before the Quarterly canary; thereby assuring - >> after the canary is issued - that his quarterly update(s) was not >> back-doored. This could be a disaster if an accidentally flawed update >> happened to get out. >> >> Please consider *increasing* the frequency of canaries - not decreasing. >> Alternatively, consider issuing additional canaries shortly after >> important system updates, and scheduling "minor" system updates a week >> before the quarterly canary. >> >> A weekly canary would be much more useful and reassuring, as I wouldn't >> have to wait to do updates. Also, ISTM weekly would be easier for ITL to >> manage. >> > I agree on the frequency point. But surely a cautious user will not > install updates until immediately AFTER the Quarterly canary, not > before. And since the canary dates are not fixed, how is one to know > when "immediately before" might be? > > 1. The canary needs to be issued on a fixed date for the system to work; otherwise a "late" canary is meaningless. 2. Certainly the back-door and gag order will be mandated immediately after the canary. So any updates after the canary are no longer trustworthy. Any updates after the date of the most recent canary can be compromised. IF you update immediately before the date-certain canary, and then discover that the canary is not updated or otherwise untrustworthy, you then restore to the last known-good backup (and seek an explanation). -- 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/012fa555-c3ca-f2e4-fc06-7b40791634fb%40gmail.com. For more options, visit https://groups.google.com/d/optout. -- 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/5f8MO5O2Wc80Xuh
