[qubes-users] Windows 10 InPrivate Desktop
https://arstechnica.com/staff/2018/08/windows-10-to-get-disposable-sandboxes-for-dodgy-apps/ "Microsoft is building a new Windows 10 sandboxing feature that will let users run untrusted software in a virtualized environment that's discarded when the program finishes running." Nice of Microsoft to finally join the party. It fails to answer what the untrusted software known as Windows 10 should be run in, though. Turtles all the way down? -- 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/9d37c5ce9bb88f0b5fcf7460cbfd9894.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Whonix 14 installation problem...using 4.0?
On Sun, August 12, 2018 10:52 pm, sm...@tutamail.com wrote: > I tried installing whonix 14 and it didn't install...followed these > instructions: > https://www.whonix.org/wiki/Qubes/Install > > After issuing the following command: sudo qubesctl state.sls > qvm.anon-whonix I get the following message in dom0 terminal - 'state.sls > qvm.anon-whonix" is not available...Dom0 configuration failed, not > continuing. Try rebooting and the above command again. -- 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/b94f4bd7b0e2cc19f715a502c12c7c3e.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Whonix 14 - upgrade or re-install? Whats more smooth, less troublesome?
On Sun, Aug 12, 2018 at 9:48 PM, Chris Laprise wrote: > On 08/12/2018 05:23 PM, Andrew David Wong wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA512 >> >> On 2018-08-12 14:26, 'awokd' via qubes-users wrote: >> >>> On Sun, August 12, 2018 6:16 pm, qubes-...@tutanota.com wrote: >>> I am planning to move from my Whonix 13 to Whonix 14 on Qubes. My question is what way it should be easier, based on the Q user experiences. What would you propose - upgrade or re-install? Are there any known issues which would call for one or other way? >>> >>> Re-install is usually easier. >>> >>> I have few VMs based on the Whonix template with data and settings on it. Will the contents of these VMs remain, or will it be destroyed - re-install vs upgrade? >>> >>> Contents should remain, just set them to the new Whonix template. >>> Make sure to back up everything first. >>> >>> >> The installation guide [1] states: >> >> "Re-installation will destroy any existing user data stored in Whonix >> VMs, unless it is backed up first. To avoid this scenario, it is >> possible to upgrade Whonix 13 to 14 instead of following these >> instructions." >> >> This was puzzling to me, too, since TemplateVM upgrades usually don't >> affect user data in TemplateBasedVMs. Could you shed some light on >> this, Patrick? >> > > What I did: Cloned the old whonix-ws template, switched appvms to the > clone, then did 'dnf remove' on the old templates and finally performed the > recommended whonix install procedure. > > Later, I was able to switch existing whonix appVMs to whonix-ws-14. > > Brilliant, thanks Chris > -- > > Chris Laprise, tas...@posteo.net > https://github.com/tasket > https://twitter.com/ttaskett > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 > > -- > 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/ms > gid/qubes-users/4433888d-cbfe-8ea2-2143-1ba4a0dcae0e%40posteo.net. > > 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/CAPzH-qAUsLTZSs17VUgkfrzLh1dLMPCLb4Vxk6rY2vELNixQ%2Bw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Things to do in Qubes before a BIOS update
On Sunday, August 12, 2018 at 5:36:17 PM UTC+2, Unman wrote: > On Sat, Aug 11, 2018 at 09:52:16PM -0700, Marcus Linsner wrote: > > Hello. > > > > I'm attempting to flash a new BIOS (ie. upgrade) and I am greeted by the > > BIOS with the following message: > > > > "Important Notice!!! > > Please back up your Bitlocker recovery key and suspend Bitlocker encryption > > in the operating system before updating your BIOS or ME firmware." > > > > Is there something that I need to do in Qubes (R4.0) before updating BIOS > > assuming either of the following: > > 1. I don't have Anti Evil Maid installed > > 2. I do have AEM installed. > > > > while Secure Boot is Enabled in BIOS and so is TPM (1.3) ? > > > > In the case of point 2 the following info exists: > > > > "Xen/kernel/BIOS/firmware upgrades > > == > > > > After Xen, kernel, BIOS, or firmware upgrades, you will need to reboot > > and enter your disk decryption passphrase even though you can't see your > > secret. Please note that you will see a `Freshness toekn unsealing failed!` > > error. It (along with your AEM secrets) will be resealed again automatically > > later in the boot process (see step 4.a). > > > > Some additional things that can cause AEM secrets and freshness token to > > fail to unseal (non-exhaustive list): > > > > * changing the LUKS header of the encrypted root partition > > * modifying the initrd (adding/removing files or just re-generating it) > > * changing kernel commandline parameters in GRUB" > > > > that is from > > https://github.com/QubesOS/qubes-antievilmaid/blob/af4f6160dfd89d126b923c183b5a9cea18b4b1b9/anti-evil-maid/README#L344-L358 > > > > > > In the case of point 1, what I want to know is whether or not I will still > > be able to boot my existing Qubes R4.0 installation after the BIOS update > > and if not how can it be fixed? This is the reason for this post. > > > > If you have replaced your windows installation completely then I dont > think you need to do anything in case 1. At least, I have flashed BIOS > a number of times and not encounterd problems in that situation. ymmv. > Obviously you should take full backup before doing this. Thanks Unman. I have upgraded BIOS successfully and there were no issues booting Qubes afterwards. -- 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/17e7146b-ccf3-43d2-beaf-84b6c001475d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Whonix 14 - upgrade or re-install? Whats more smooth, less troublesome?
On 08/12/2018 05:23 PM, Andrew David Wong wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2018-08-12 14:26, 'awokd' via qubes-users wrote: On Sun, August 12, 2018 6:16 pm, qubes-...@tutanota.com wrote: I am planning to move from my Whonix 13 to Whonix 14 on Qubes. My question is what way it should be easier, based on the Q user experiences. What would you propose - upgrade or re-install? Are there any known issues which would call for one or other way? Re-install is usually easier. I have few VMs based on the Whonix template with data and settings on it. Will the contents of these VMs remain, or will it be destroyed - re-install vs upgrade? Contents should remain, just set them to the new Whonix template. Make sure to back up everything first. The installation guide [1] states: "Re-installation will destroy any existing user data stored in Whonix VMs, unless it is backed up first. To avoid this scenario, it is possible to upgrade Whonix 13 to 14 instead of following these instructions." This was puzzling to me, too, since TemplateVM upgrades usually don't affect user data in TemplateBasedVMs. Could you shed some light on this, Patrick? What I did: Cloned the old whonix-ws template, switched appvms to the clone, then did 'dnf remove' on the old templates and finally performed the recommended whonix install procedure. Later, I was able to switch existing whonix appVMs to whonix-ws-14. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- 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/4433888d-cbfe-8ea2-2143-1ba4a0dcae0e%40posteo.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Whonix 14 installation problem...using 4.0?
I tried installing whonix 14 and it didn't install...followed these instructions: https://www.whonix.org/wiki/Qubes/Install Removed old Whonix templates and VMs (Not sure I was supposed to but the instructions state to remove old version) Updated Dom0 I then did the following command in Dom0 per the Whonix instruction: sudo qubes-dom0-update qubes-core-admin-addon-whonix (Didn't seem like a typical template install/reinstall) This is where things broke down and I think I messed up, that is, after I entered the following: sudo qubesctl state.sls qvm.anon-whonix First time I have used salt or issued this type command (Didn't seem like a normal Qubes template update or re-install), Dom0 terminal just seemed to stall I found this article that might be similar: https://groups.google.com/forum/#!searchin/qubes-users/whonix$2014%7Csort:date/qubes-users/A_CYJchSZBQ/BcuMjY6LDwAJ Now I think I screwed this up even more: 1) I originally closed the Dom0 terminal, likely messing up the download, salt process or something else. It looked like dom0 had stalled (not uncommon based on my GUI dom0 update experience) 2) I found the whonix-14-gw installed but whonix-14-ws did not 3) I removed/deleted the templates based on the following 4.0 instructions: https://www.qubes-os.org/doc/templates/ specifically I issued the following command for whonix-14-dvm, whonix-14-gw, whonix-14-ws(whose template was blank). The thinking was just to try again. 4) I tried the instructions again on: https://www.whonix.org/wiki/Qubes/Install and dom0 states: After issuing the following command: sudo qubes-dom0-update qubes-core-admin-addon-whonix I get the following message in dom0 terminal - qubes-core-admin-whonix-4.0.1-1.fc25 noarch is already installednothing to do.complete After issuing the following command: sudo qubesctl state.sls qvm.anon-whonix I get the following message in dom0 terminal - 'state.sls qvm.anon-whonix" is not available...Dom0 configuration failed, not continuing. Per the whonix instructions, I tried sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-mgmt-salt-dom0-virtual-machines I get the following message in dom0 terminal "...is already installed, skipping. Dependencies resolved. Nothing to do. Complete!" My questions are: 1) How can I try to install whonix 14 again? 2) Did I just screw up my system with these edits and changes? If so how do I undo? Thanks for any ideas or help -- 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/f5773e2a-e64f-4c7c-84de-22d9bc4ac5e2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Whonix 14 - upgrade or re-install? Whats more smooth, less troublesome?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2018-08-12 14:26, 'awokd' via qubes-users wrote: > On Sun, August 12, 2018 6:16 pm, qubes-...@tutanota.com wrote: >> I am planning to move from my Whonix 13 to Whonix 14 on Qubes. My >> question is what way it should be easier, based on the Q user >> experiences. What would you propose - upgrade or re-install? Are >> there any known issues which would call for one or other way? > > Re-install is usually easier. > >> I have few VMs based on the Whonix template with data and >> settings on it. Will the contents of these VMs remain, or will >> it be destroyed - re-install vs upgrade? > > Contents should remain, just set them to the new Whonix template. > Make sure to back up everything first. > The installation guide [1] states: "Re-installation will destroy any existing user data stored in Whonix VMs, unless it is backed up first. To avoid this scenario, it is possible to upgrade Whonix 13 to 14 instead of following these instructions." This was puzzling to me, too, since TemplateVM upgrades usually don't affect user data in TemplateBasedVMs. Could you shed some light on this, Patrick? [1] https://www.whonix.org/wiki/Qubes/Install - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAltwpWUACgkQ203TvDlQ MDDAJxAAoVPnbBU2gLdc6tqrRON85t7R21i5ug5BjTAsI88Zo4miCa6+lpGC2lhw Moec3+JcrlseWhGfYjNqP53fwbZkds+nrRoqiNn/XEz24ZRNMcRWQQaaNefEuEkq cMRrjGnIZGzm02TrO4llb4FnZ0jq2bktlYFLgI3X6m+fd94uaAF02t5XM+4uKI// fyprLeFqgYfBHR9C2dwY+GendDSWtse+m28b5fOBwObZpIND/uGd7iA3uZA+WdyQ WkgD5OkzBRU9P5l2vCPQZccc3Il/rZW5ktEhzKq9LoGvbY2rm6XFgYwOuX3jHy3F BhFalePPf84I+sHp2b6wRRbrE8AKApoELJ3Km64iIk8ZnpXlQmSyhG1RuDaa7y3k OK86nzHPEGU+69ALJF60kU+1ceAfVWyJOf5eOmjeRoXxawly00/SERP27iE8eKLG 0kwAoSOf3Q1Cw9XxqwH7b6NElwUR09+A5rw05zyxQBtGpSfyo9iDINJkh6fQA+Wu AdQpjij+2bIlnShrhvSyScdp4DRIeGcLdtjiAfbUkEp11opMVDf+4mlDfD8bVJlD FscBLdo2s8Ee5RnJ7BTADF35WwvDb5xT0zzoV+R5W69veLa7i8GqnOOoX01DJoqL Zm9t+8vNeR0H5s+vjo+gLyilCHEOV55yRc1JOeiWYzLogSK/248= =sp1V -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/bee0944e-c849-9888-23b8-e53e7bb4%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Installation guide warnings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2018-08-12 05:15, oliver.salzb...@gmail.com wrote: > The installation guide at > https://www.qubes-os.org/doc/installation-guide/ has a set of > warnings at the top. To me, it is not quite clear how much of that > is relevant when installing 4.0. It would be nice if that could be > made clearer. > Fixed. > Further down, there's a warning "If you do that on Windows 10, you > can only install Qubes without MediaTest, which isn’t recommended." > It's not clear to me to what part of the process that warning > refers to and why it is not recommended. > Not sure about this part, sorry. - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAltwoo4ACgkQ203TvDlQ MDA7tQ/+IAdviYsznEJmU2wn3YeZIDefVOzcmJ9IAwwKCcJkSBlu4isr94dRVWSB NaJgBjWjSsJv5sznNiuEd5B+P7oSZjF9VbrN+1rr9Unsnh1+TwCkL8JwM/H2ZpWj OZ6IMF8gPQepg6qI4ohIR7GQh7DgY9fRlvCfEGaQ3J964MqBYXV5GI4IR8UAO6ZV Ua9d1f6GRz6ILHJ7lz+1Z76xoISxelY+DBmnfdJV5vd10ZOyfY72qIGhXENWexiJ yIF6OxOzxXkDpIT5cv7CT07LlGb0O8kzM/2+r6m0ITDYxjHI/8kXuHCx45t7xqnT bJgDMdUvY8TJJaJFovMj0CFiEpxt7Ug9pVWKlM8M2iP46tVoxrTcAQEXYgMH2Nj1 v/YkYvC8qSwAT42X23WdqbBBbr7xwogmZ+vGZTvtTrKv3I0gh1i5dtNbvZVuU0FQ ZevqcWljgYo9EAP1H5unrsy2teTG/NUGZ/9HmAL4iWjbtmX3T4YKxXH4krVVVMAh XuWp3KOFIJ7SVVz/HnJuak0M1NkWA+6GRCitIdpFvrP0cMMTLyOzBLwCNzxZI+i3 cwwpMNPw+ArVE+H3SaGJrX7vlC/PbO7azJuR9Ihgs9KhV5//ItHoylIsBzT1ZuGX NdifC+DvIw9jhftBalrf5eZfy/xeKdyLjez7Cz9Jmuj3i2TJ3Ls= =H0ao -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/500e97ee-db36-8483-ee99-6042b2199f66%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] how to connect USB to standalone HVM Kali
On Sat, August 11, 2018 11:56 am, bbbenjjjami...@gmail.com wrote: > how to connect USB to standalone HVM Kali? Try cloning debian-9 to a new standalone HVM, then installing Kali on top of it. -- 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/89e6c78be31b2e91dd69ef13664a0833.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Extreme CPU usage by dom0 on Qubes 4.0
On Fri, August 10, 2018 7:09 pm, Kelly Dean wrote: > For no apparent reason, dom0 suddenly starting consuming practually all > CPU power, and the system is unusably sluggish. Have a dual core Core-i3, > and xentop says dom0 is taking anywhere from 112% to 201% CPU. > > top in dom0 shows load average ranging from 2 to 3. Occasionally qubesd, > qvm-pool, or qubes-qube-manager are shown taking around 25% CPU, but > usually nothing over 10%. > > I commonly have disk thrashing on this system, but right now I have > practically no disk activity, so the problem must be something else. I > also paused my non-essential qubes, but to no avail. The problem is in > dom0. > > I've been running 4.0 for 4 months, and have had other problems > (spontaneous rebooting, which I also had on 3.2, and excessive HD > thrashing, new to 4.0), but this is the first time I've ever had dom0 > make the system completely unusable, with no solution other than > rebooting. > > Note, I'm posting several messages today about other problems too, just > because I've become aggravated enough. I don't think they have anything > to do with each other. I haven't had any of those problems you listed. Only thing I can think of are the basics- have you installed anything in dom0? Did you install a release candidate of Qubes, then upgrade? Do you have enough RAM to comfortably support the amount of running VMs? -- 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/100e2f319e289d08ac4d5c48d0e48c7d.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Updated HCL report - Dell Precision 5520
On Thu, August 9, 2018 4:29 pm, Jim Snider wrote: > FOLLOW UP NOTE: I would like to try again to install Qubes UEFI from the > dd produced usb but I have not been able to edit the READ-ONLY > /EFI/BOOT/BOOTX64.cfg file to make the needed kernel options. Either, I > have not been able to get the option line to display options to make > edits during install, so i had to resort to installing Legacy so I could > edit BOOTX64.cfg and/or make boot option changes from the install screen. Did you see the steps here? https://www.qubes-os.org/doc/uefi-troubleshooting/#change-installer-kernel-parameters-in-uefi You have to boot some other Linux instance, then mount the partition in there to edit it. -- 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/b7b15ad28f6f670b571f468258310ba2.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] I want to use a HVM as a NetVM, cat assign vif+ interface
On Wed, August 8, 2018 5:53 pm, Andreas Moreiro wrote: > > Qubes dev said in his last post here, that it can not be done in 2014. > https://groups.google.com/d/topic/qubes-users/RFXoZ3zt-PE > > > I tried it for myself, and I can assign the PCI device, and get an eth0 > interface, however I can't assign the virtual interface vif+ to the HVM. > > I tried attaching in Dom0 with: > xl network-attach whonix-gw-clone-1 script=/etc/xen/scripts/vif-route-qubes > ip=... backend=firewallVM and got an error: libx: > error:libx.c:2044device_addrm_aocomplete: unable to add device > > > > Tried to start the firewallvm, with the HVM as its netVM, and got these > errors in the log: > > libxl_device.c:1081:device_backend_callback: unable to add device with > path libxl_device.c:1512:device_attach_devices: unable to add nic devices > libxl_device.c:1081:device_backend_callback: unable to remove device with > path libxl.c:1669:devices_destroy_cb: libxl_devices_destroy failed > > > i used some parts of this tutorial for inspiration: > https://garlicgambit.wordpress.com/2016/04/22/how-to-run-tails-from-a-qub > es-live-cd/ > > Thanks for reading. Any suggestions? Sys-net is already an HVM. Are you trying to make a custom template? You shouldn't have to manually assign interfaces. Did you check the "provides network" box when creating your custom sys-net? -- 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/7fc023164d6dc45068ff1d625c0b0da0.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] X470 and IOMMU Groups...
On Wed, August 8, 2018 5:30 pm, 3mp...@gmail.com wrote: > Hi everyone, > > > actually I'm a happy Qubes 3.2 user on Intel platform for more than a > year now ! > > I'm looking to upgrade my actual Skylake build with an AMD one with the > new Ryzen Pinnacle Ridge CPU (R7 2700) and installing Qubes 4.0 on the > same occasion. The Asrock X470 Taichi seems a really nice motherboard for > it. > > I've found the IOMMU Groups of this motherboard on reddit : > https://www.reddit.com/r/VFIO/comments/8i8yqq/iommu_groups_for_asrock_tai > chi_x470/ > > and it seems there's a big group 13 with LAN, USB and SATA controllers. I > wonder if the netVM and USB VM will actually be able to passthrough these > controllers if they are in the same IOMMU Group ? > > Any Ryzen / Qubes users can confirm this works OK or this is a no go ? No experience with that exact configuration. You can often passthrough devices individually even if they are in the same IOMMU group (older versions of Xen had trouble). Suggest buying from some place with a good return policy. -- 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/15dd6bb74a6681422c487310cbede169.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] occasional hangs that stop trackpad and keyboard entry
On Wed, August 8, 2018 1:00 pm, trueriver wrote: > Asus laptop UX 360 c. Trackpad, touchscreen, 4G memory (yes I know, that > is small for Qubes), SSD drive. > > I am getting occasional hangups where actions on the keyboard and > trackpad are ignored. Sometimes this is a few seconds, sometimes longer, > very occasionally it is a cup of tea job. > > One guess as to what is happening is that the trackpad driver in Dom0 > gets some vital part swapped out, and it is a while before it is swapped > back in. To test this guess, is there a way I can lock the trackpad > driver in real memory? > > Another guess is that this is due to an unwanted "takeover" by the > unwanted touch screen. How can I permanently disable the touch screen in > Dom0 to test this guess. > > > IF either guess turns out to be right, it will of course be elevated to > have been a hypothesis all along ;) My guess would be that 4G of RAM too; it's probably swapping like you said. You can try to fine tune your max RAM allocations per VM, but 8G should really be considered the minimum. -- 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/f89021a892aaa84d8091fafcad2b1bbd.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Whonix 14 - upgrade or re-install? Whats more smooth, less troublesome?
On Sun, August 12, 2018 6:16 pm, qubes-...@tutanota.com wrote: > I am planning to move from my Whonix 13 to Whonix 14 on Qubes. My > question is what way it should be easier, based on the Q user > experiences. What would you propose - upgrade or re-install? Are there > any known issues which would call for one or other way? Re-install is usually easier. > I have few VMs based on the Whonix template with data and settings on it. > Will the contents of these VMs remain, or will it be destroyed - > re-install vs upgrade? Contents should remain, just set them to the new Whonix template. Make sure to back up everything first. -- 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/95804258a6e66c35542d33cf81410e1e.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Minimal builder.conf and template security
On Sun, August 12, 2018 2:09 pm, Unman wrote: > On Fri, Aug 10, 2018 at 09:01:46PM -, 'awokd' via qubes-users wrote: > >> On Fri, August 10, 2018 6:43 pm, bobthebuil...@tutamail.com wrote: >> >>> What is the minimal configuration for building qubes? I want to build >>> a custom iso minus most of the templates so I only need dom0, netvm, >>> usbvm and whonix. Are there any components that always need to build >>> or can the whole iso be build from packages and templates in the yum >>> or deb repository? Are templates in the repositories automatically >>> rebuild and uploaded so the latest bugfixes are always integrated or >>> do you need to update the templates yourself? >> >> See https://www.qubes-os.org/doc/qubes-r3-building/ for steps on how to >> build. You might be able to use Fedora 28 instead of 26, but I haven't >> fully tested. From your list of "dom0, netvm, usbvm and whonix", the >> only template you could exclude is debian-9. All templates and build >> components get updated to current levels on a full build, so you >> shouldn't have to update immediately after installing it. >> > > If you want Whonix then you *have* to include debian-9 I think: aren't > the whonix templates configured off the debian-9 base? You have to include the debian builder to build Whonix templates, but I'm not positive about the actual debian-9 template. > The templates in the repositories are rebuilt, but do not always > incorporate the latest bugfixes. It's good practice to immediately update > after installing a new template. (If you roll your own, of course, you > wont have this issue.) A full build downloads/syncs everything off Qubes' repos and current distribution patches. What other bugfixes are there? -- 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/c0f9806f1e266788760cbcc71212f89f.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Copy & Paste into anouther Domains
Hey, i want copy a file from Sys-net to my Windows-VM first step: when i click Ctrl+c in the source VM (Sys:net)nothing happend(cant see anything). When i clicked in the main folder and copy the file(Ctrl+Shift+c) i become a successfully message. 2 Step: Now i type the command "Ctrl+Shift+v and change to my WindowsVM and try copy the file with following command Ctrl+v. I only copy some windows files but not the fie which lay on the sys-net Stick. I tried everything but nothing want work. Some ideas? -- 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/3a3e31f1-e154-49b6-b3c9-1bed990f93cc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Whonix 14 - upgrade or re-install? Whats more smooth, less troublesome?
I am planning to move from my Whonix 13 to Whonix 14 on Qubes. My question is what way it should be easier, based on the Q user experiences. What would you propose - upgrade or re-install? Are there any known issues which would call for one or other way? I have few VMs based on the Whonix template with data and settings on it. Will the contents of these VMs remain, or will it be destroyed - re-install vs upgrade? Thank you -- 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/LJjLgjh--3-1%40tutanota.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Copy & Paste into anouther Domains
Hey, i wrote the command promp correct in the guid.conf but wrong here sorry. VM Xy: } secure_copy_sequence ="Ctrl+Shift+c; secure_paste_sequence ="Ctrl+Shift+v; }; Workspace1: If i copy the file i see a qubes Windows which show me how many byte i copy t the clipboard. After this command i change to Workspace 2 where i want paste it. But nothing happened. On Workspace 2 Windows run and i try to paste the file on the Desktop,there. What iam doing wrong? -- 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/f073b4ed-9447-418b-918e-a378896c96d5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: yubikey password
On Sunday, 12 August 2018 09:59:57 UTC-4, Unman wrote: > On Fri, Aug 10, 2018 at 11:00:30AM -0700, : > > On Friday, 10 August 2018 11:31:08 UTC-4, Unman wrote: > > > On Fri, Aug 10, 2018 at 07:39:45AM -0700, > > > > Both /etc/qubes-rpc/policy/qubes.InputKeyboard and InputMouse, should > > > > say something like this. > > > > > > > > sys-usb dom0 allow,user=root > > > > > > > > Yes, If you have a sys-usb set up, then the USB keyboard will attach > > > > there first. More specifically, the USB Host Controller that the USB > > > > keyboard is plugged into is attached to sys-usb. But the keyboard > > > > device is immediately sent to dom0 per the rpc policy. Because a > > > > keyboard that stays attached to sys-usb, can only type into sys-usb. > > > > And not the interactive window you see when you open up a terminal for > > > > sys-usb... but rather its own session. > > > > dom0 needs the keyboard and mouse. The USB Host Controller still > > > > resides in sys-usb, but the USB raw data passes to dom0 upon boot. > > > > > > > > Unfortunately, the rpc policy is generic based on all USB devices > > > > enumerating as a keyboard. So it may not be able to selectively attach > > > > a yubikey to an AppVM. > > > > > > > > > > But the point is that the yubikey will be attached to a different qube, > > > and can be treated as a keyboard there. This means that one can > > > selectively link the yubikey to distinct qubes for input there, and the > > > sys-usb policy will not be relevant. > > > The Input.Keyboard policy needs to be set for the qube to which the > > > yubikey is attached. > > > > Yeah, that would be nice if it were that granular. > > > > I don't have my yubikey set for a static key, but let me test this with my > > input stick, which is like a USB rubber ducky. It enumerator as a > > keyboard, and I have just attached it to the app VM I am typing on. > > I am speech to text on my phone, Bluetooth to InputStick USB and typing > > into here. > > > > It only works with, "sys-usb dom0 allow,user=root" in > > /etc/qubes-rpc/policy/qubes.InputKeyboard > > And it does NOT work with "sys-usb APPVM_NAME allow,user=root". > > No USB device attaching is needed, as the rpc rule simple allows dom0 > > access to sys-usb keyboard. > > > > As I said... Keyboards need to be sent to dom0, or else it cannot type in > > the GUI. > > > > This will work for all USB keyboards as you cannot specify Yubikey > > keystrokes only type in a single AppVM. Not the most secure... which is > > why Qubes recommends PS2 keyboards if running on a desktop and using the > > built in keyboard on laptops. It avoids the USB blanket rule for keyboards > > going to dom0. And since LUKS encryption passphrases are entered after > > initramfs hides usb from boot process, a non-usb keyboard is essential for > > full disk encryption. > > > > All that said, > > it is still a much more secure option to use ykchalresp which comes with > > yubikey tools. The USB device that does this function is not the keyboard > > part, and you have to explicitly Attach to the VM you want. Also, no > > static key to be sniffed or accidentally typed somewhere. I use it for > > KeePass, LUKS, PAM.d login, OTP tokens, everything. > > > > > > What you say about connecting keyboards isn't quite true. > If you have passed the device through to a qube, then you need to set > the policy *for that qube*. i.e - > dom0 allow, user=root > > I don't use yubikeys so I cant speak for them, but that works for > keyboards. It does mean that the attached keyboard input *could* be sent to > any qube after user error. > > Of course, the granularity of passthrough is currently missing, but it's > possible > to hack this in various ways. > > If you create a HVM and assign it a USB controller, then usb attached > devices can insert key strokes *without* using qubes.InputKeyboard. This > looks like a reasonable approach if you have more than one controller, > and keeps the usb keystrokes confined to the qube. > > If you only have one controller, then you could stop the Sender service > in the qube, let the keyboard do it's stuff in that qube, remove the > yubikey, and then re-enable the service. A bit unwieldy but security > always comes at a price, and you could automate this with a key > combination. > > It's also possible to use qrexec to directly pass keystrokes from one > qube to another. You can manually run the input proxy service and pipe > it through to another qube. I've hacked this via dom0 (poc) and it works > fine - you also need to process the /dev/input/event input to generate > keyboard input in X in the qube, but that's pretty standard. If it's of > interest I could work this up. > > unman > "If you have passed the device through to a qube, then you need to set the policy *for that qube*. i.e - dom0 allow, user=root " Yes, and I did say that before, "It only works with, "sys-usb dom0 allow,user=root" in
Re: [qubes-users] Things to do in Qubes before a BIOS update
On Sat, Aug 11, 2018 at 09:52:16PM -0700, Marcus Linsner wrote: > Hello. > > I'm attempting to flash a new BIOS (ie. upgrade) and I am greeted by the BIOS > with the following message: > > "Important Notice!!! > Please back up your Bitlocker recovery key and suspend Bitlocker encryption > in the operating system before updating your BIOS or ME firmware." > > Is there something that I need to do in Qubes (R4.0) before updating BIOS > assuming either of the following: > 1. I don't have Anti Evil Maid installed > 2. I do have AEM installed. > > while Secure Boot is Enabled in BIOS and so is TPM (1.3) ? > > In the case of point 2 the following info exists: > > "Xen/kernel/BIOS/firmware upgrades > == > > After Xen, kernel, BIOS, or firmware upgrades, you will need to reboot > and enter your disk decryption passphrase even though you can't see your > secret. Please note that you will see a `Freshness toekn unsealing failed!` > error. It (along with your AEM secrets) will be resealed again automatically > later in the boot process (see step 4.a). > > Some additional things that can cause AEM secrets and freshness token to > fail to unseal (non-exhaustive list): > > * changing the LUKS header of the encrypted root partition > * modifying the initrd (adding/removing files or just re-generating it) > * changing kernel commandline parameters in GRUB" > > that is from > https://github.com/QubesOS/qubes-antievilmaid/blob/af4f6160dfd89d126b923c183b5a9cea18b4b1b9/anti-evil-maid/README#L344-L358 > > > In the case of point 1, what I want to know is whether or not I will still be > able to boot my existing Qubes R4.0 installation after the BIOS update and if > not how can it be fixed? This is the reason for this post. > If you have replaced your windows installation completely then I dont think you need to do anything in case 1. At least, I have flashed BIOS a number of times and not encounterd problems in that situation. ymmv. Obviously you should take full backup before doing this. -- 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/20180812153615.zjkfq3n7edkzmxko%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Copy & Paste into anouther Domains
On Sun, Aug 12, 2018 at 07:38:37AM -0700, myblackcatisb...@gmail.com wrote:
> Hey guys,
>
> i tried to copy files from my USB-Stick (sys:net) to my new created Windows7
> HVM Domain.
>
> First i made some settings in the /etc/qubes/guid.conf settings and set in
> the part VM following commands.
>
> VM XY: {
>
> secure_paste_sequence = "Crtl-Shift-v"
> secure_paste_sequence = "Crtl-Shift-c"
> };
>
> On the Qubes main site i found the tutorial how to copy and paste files to
> anouther VM(Domain)
>
> Domain 1 XY is on Workspace 2
> Sys-net(USB-Stick) is on Workspace 1
>
> Now i go into Workspace 1 and copy the file with Ctrl+Shift+c
> After this i go to Workspace 1 and want copy this file on the WindowsHVM with
> Crtl+Shift+v but nothing happened.
>
> What iam doing wrong?
>
> About your help i would be happy
>
> regards
>
You have installed the Qubes Windows Tools?
Also, there's some errors in your settings - you seem to have
secure_paste_sequence defined twice, if that isn't just a typo.
And you don't say that you are actually copying the file before
Ctrl+Shift+c., and then using Ctrl+V or Edit-Paste to paste in to the
target.
Can you check that you are able to Copy/Paste to another Linux 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/20180812152919.zdctk3koh3wzqfla%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] Copy & Paste into anouther Domains
Hey guys,
i tried to copy files from my USB-Stick (sys:net) to my new created Windows7
HVM Domain.
First i made some settings in the /etc/qubes/guid.conf settings and set in the
part VM following commands.
VM XY: {
secure_paste_sequence = "Crtl-Shift-v"
secure_paste_sequence = "Crtl-Shift-c"
};
On the Qubes main site i found the tutorial how to copy and paste files to
anouther VM(Domain)
Domain 1 XY is on Workspace 2
Sys-net(USB-Stick) is on Workspace 1
Now i go into Workspace 1 and copy the file with Ctrl+Shift+c
After this i go to Workspace 1 and want copy this file on the WindowsHVM with
Crtl+Shift+v but nothing happened.
What iam doing wrong?
About your help i would be happy
regards
--
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/4a0094aa-b795-4522-af42-12d35cb8ad50%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Incredible HD thrashing on 4.0
On Sat, Aug 11, 2018 at 12:44:18AM -0400, Chris Laprise wrote: > On 08/10/2018 03:02 PM, Kelly Dean wrote: > > Has anybody else used both Qubes 3.2 and 4.0 on a system with a HD, not > > SSD? Have you noticed the disk thrashing to be far worse under 4.0? I > > suspect it might have something to do with the new use of LVM combining > > snapshots with thin provisioning. > > > > The problem seems to be triggered by individual qubes doing ordinary bursts > > of disk access, such as loading a program or accessing swap, which would > > normally take just a few seconds on Qubes 3.2, but dom0 then massively > > multiplies that I/O on Qubes 4.0, leading to disk thrashing that drags on > > for minutes at a time, and in some cases, more than an hour. > > > > iotop in dom0 says the thrashing procs are e.g. [21.xvda-0] and > > [21.xvda-1], reading the disk at rates ranging from 10 to 50 MBps (max > > throughput of the disk is about 100). At this rate, for how prolonged the > > thrashing is, it could have read and re-read the entire virtual disk > > multiple times over, so there's something extremely inefficient going on. > > > > Is there any solution other than installing a SSD? I'd prefer not to have > > to add hardware to solve a software performance regression. > > > > I really don't know if LVM or Ext4 have an SSD/HDD mode, but Btrfs does. The > HDD mode avoids some thrashing. > > Also, I remember installing a 4.0 release candidate on an external HDD and > didn't note unusual thrashing at the time. > > > -- > > Chris Laprise, tas...@posteo.net > https://github.com/tasket > https://twitter.com/ttaskett > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 I don't recognise this on a somewhat under powered laptop with HDD - definitely not "minutes at a time". Is there something significant about the disks that you cite, or are those just examples? -- 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/20180812141347.obgxvajspbgblmmt%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Minimal builder.conf and template security
On Fri, Aug 10, 2018 at 09:01:46PM -, 'awokd' via qubes-users wrote: > On Fri, August 10, 2018 6:43 pm, bobthebuil...@tutamail.com wrote: > > What is the minimal configuration for building qubes? I want to build a > > custom iso minus most of the templates so I only need dom0, netvm, usbvm > > and whonix. Are there any components that always need to build or can the > > whole iso be build from packages and templates in the yum or deb > > repository? Are templates in the repositories automatically rebuild and > > uploaded so the latest bugfixes are always integrated or do you need to > > update the templates yourself? > > See https://www.qubes-os.org/doc/qubes-r3-building/ for steps on how to > build. You might be able to use Fedora 28 instead of 26, but I haven't > fully tested. From your list of "dom0, netvm, usbvm and whonix", the only > template you could exclude is debian-9. All templates and build components > get updated to current levels on a full build, so you shouldn't have to > update immediately after installing it. > If you want Whonix then you *have* to include debian-9 I think: aren't the whonix templates configured off the debian-9 base? If you are building an iso from scratch you can include custom templates that you have built - for example, a minimal debian with additional networking and usb packages - in preference to the Qubes standards. You can drop Fedora templates alltogether. Remember to edit the salt packages appropriately. Otherwise you can just build a barebones iso, install without creating any qubes, and then manually configure them using the template you have included. The templates in the repositories are rebuilt, but do not always incorporate the latest bugfixes. It's good practice to immediately update after installing a new template. (If you roll your own, of course, you wont have this issue.) 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/20180812140918.qdoz4ckejoerg77r%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: yubikey password
On Fri, Aug 10, 2018 at 11:00:30AM -0700, joevio...@gmail.com wrote: > On Friday, 10 August 2018 11:31:08 UTC-4, Unman wrote: > > On Fri, Aug 10, 2018 at 07:39:45AM -0700, > > > Both /etc/qubes-rpc/policy/qubes.InputKeyboard and InputMouse, should say > > > something like this. > > > > > > sys-usb dom0 allow,user=root > > > > > > Yes, If you have a sys-usb set up, then the USB keyboard will attach > > > there first. More specifically, the USB Host Controller that the USB > > > keyboard is plugged into is attached to sys-usb. But the keyboard device > > > is immediately sent to dom0 per the rpc policy. Because a keyboard that > > > stays attached to sys-usb, can only type into sys-usb. And not the > > > interactive window you see when you open up a terminal for sys-usb... but > > > rather its own session. > > > dom0 needs the keyboard and mouse. The USB Host Controller still resides > > > in sys-usb, but the USB raw data passes to dom0 upon boot. > > > > > > Unfortunately, the rpc policy is generic based on all USB devices > > > enumerating as a keyboard. So it may not be able to selectively attach a > > > yubikey to an AppVM. > > > > > > > But the point is that the yubikey will be attached to a different qube, > > and can be treated as a keyboard there. This means that one can > > selectively link the yubikey to distinct qubes for input there, and the > > sys-usb policy will not be relevant. > > The Input.Keyboard policy needs to be set for the qube to which the > > yubikey is attached. > > Yeah, that would be nice if it were that granular. > > I don't have my yubikey set for a static key, but let me test this with my > input stick, which is like a USB rubber ducky. It enumerator as a keyboard, > and I have just attached it to the app VM I am typing on. > I am speech to text on my phone, Bluetooth to InputStick USB and typing into > here. > > It only works with, "sys-usb dom0 allow,user=root" in > /etc/qubes-rpc/policy/qubes.InputKeyboard > And it does NOT work with "sys-usb APPVM_NAME allow,user=root". > No USB device attaching is needed, as the rpc rule simple allows dom0 access > to sys-usb keyboard. > > As I said... Keyboards need to be sent to dom0, or else it cannot type in the > GUI. > > This will work for all USB keyboards as you cannot specify Yubikey keystrokes > only type in a single AppVM. Not the most secure... which is why Qubes > recommends PS2 keyboards if running on a desktop and using the built in > keyboard on laptops. It avoids the USB blanket rule for keyboards going to > dom0. And since LUKS encryption passphrases are entered after initramfs > hides usb from boot process, a non-usb keyboard is essential for full disk > encryption. > > All that said, > it is still a much more secure option to use ykchalresp which comes with > yubikey tools. The USB device that does this function is not the keyboard > part, and you have to explicitly Attach to the VM you want. Also, no static > key to be sniffed or accidentally typed somewhere. I use it for KeePass, > LUKS, PAM.d login, OTP tokens, everything. > > What you say about connecting keyboards isn't quite true. If you have passed the device through to a qube, then you need to set the policy *for that qube*. i.e - dom0 allow, user=root I don't use yubikeys so I cant speak for them, but that works for keyboards. It does mean that the attached keyboard input *could* be sent to any qube after user error. Of course, the granularity of passthrough is currently missing, but it's possible to hack this in various ways. If you create a HVM and assign it a USB controller, then usb attached devices can insert key strokes *without* using qubes.InputKeyboard. This looks like a reasonable approach if you have more than one controller, and keeps the usb keystrokes confined to the qube. If you only have one controller, then you could stop the Sender service in the qube, let the keyboard do it's stuff in that qube, remove the yubikey, and then re-enable the service. A bit unwieldy but security always comes at a price, and you could automate this with a key combination. It's also possible to use qrexec to directly pass keystrokes from one qube to another. You can manually run the input proxy service and pipe it through to another qube. I've hacked this via dom0 (poc) and it works fine - you also need to process the /dev/input/event input to generate keyboard input in X in the qube, but that's pretty standard. If it's of interest I could work this up. 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/20180812135954.t34vte37fare3gcq%40thirdeyesecurity.org. For
Re: [qubes-users] Network not working until several minutes after login
On Sat, Aug 11, 2018 at 12:13:32PM -0700, Andreas Rasmussen wrote: > Hi! > > For the last couple of months, my Qubes 4.0 install has suffered from a weird > bug. When I login to Qubes, my network icon shows, that I'm connected to my > wifi: No matter what VM i'm using, I cannot connect to anything online. > > However, if I wait a short while, perhaps 3-4 minutes, I can open any VM and > connect to whatever I want. > > When Qubes is booting, I get a short errormessage, that Qubes is trying to > start a nonexisting VM (which I deleted). Then it starts sys-net without > problems. I don't know if this might be relevant for the problem? > > best regards, > > Andreas > Is it possible that you are using Whonix gateway by default, and it's taking a long time to get the Tor connections set up? What does your Qubes network setup look like? -- 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/20180812133816.vtvn7w5x5wsv6zel%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: how to connect USB to standalone HVM Kali
суббота, 11 августа 2018 г., 14:56:03 UTC+3 пользователь Djon Snow написал: > how to connect USB to standalone HVM Kali? write - qrexec not connected -- 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/33ac9aef-2eac-45ef-b472-6dfe6084f89f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Installation guide warnings
The installation guide at https://www.qubes-os.org/doc/installation-guide/ has a set of warnings at the top. To me, it is not quite clear how much of that is relevant when installing 4.0. It would be nice if that could be made clearer. Further down, there's a warning "If you do that on Windows 10, you can only install Qubes without MediaTest, which isn’t recommended." It's not clear to me to what part of the process that warning refers to and why it is not recommended. Cheers -- 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/f89576fa-5e10-44e4-bf09-3265f322aa6b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
