Re: [qubes-users] HDMI-related threats in Qubes OS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2017-04-01 13:58, Vít Šesták wrote: > Hello, > I've realized that HDMI offers not only graphical/sound output, but also many > inputs. Well, some inputs are expected (listing of available output modes > etc. works AFAIK even with VGA), but others can be more or less surprising: > > * audio return channel > * CEC > * ethernet (!) > * maybe even more > > [...] > Very interesting discussion so far. Cross-linking with tracking issue: https://github.com/QubesOS/qubes-issues/issues/2743 - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJY6wJbAAoJENtN07w5UDAwLokQALhQxKKOMRyoMU17XBKT4CFe btKsznsSREzwoKwOphV0j1KBSijukjDEYVm/SVfLQfxQLRrPq+Eyv3g0D4qsM1AQ mzfJLB3On8QAq0jydUaoPDqApgKXYQQ7CKwt016p1+VUb76UR+O+89oDlISBYfiw 7qBq2gwz+Lc3Fei+27pEv22HxXSkxtNZMKtzKiMgXou2l/H3eqWvpYOlbtzWCU1p gtyj+4sVfJ9YGKWvutN/DzOyIXb1sp0DpzaZCGGpq/5NCKM5Ufg+EYbxCAduDxp/ m0sxFVnRhwcIP4zGGoMW5RHnZtwBHLP6llP55UalWaEolVH6nsS7kRELmfgYm7fw /sALreuOh/TOv2fFsDN5/Qrw/sFq3yIzQn5NHfxjYnSF5+uGWTEqa854nTPIIQR4 KFPb/BsbLPGoA+f+zDOCcKGBnTEoYpy6LL8OmaYcIODqZkDRQlK0txs4F0DHdob9 +zGwXIj94eB6XdIUACCz2kZeu7hXDRcFHlDuJ5WHn/Effuy45DQEbCztb0vDtAxd XH7mZ19Hz6GvkCzqNp9R5BSLeubDKbCx1HAmdmaa0cxsyUKt/UHIYthSrMKvPfPF GTexdTzomHs7v1LlOGT2TnYWX0xowtVWvTBFinTXusw9wfLdj7BN/REFEVDaOT/d no3IYSVHkscO/TcNGMcI =PAeU -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/3227f0e8-12de-b6b1-81de-c46cb2393762%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] for people using MAC randomization (debian 9 tmpl): you might want to avoid hostname leaks via DHCP too
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2017-04-09 15:25, Joonas Lehtonen wrote: > Hi, > > if you setup MAC randomization via network manager in a debian 9 > template as described here: > https://www.qubes-os.org/doc/anonymizing-your-mac-address/ > you still leak your hostname. > > Once your MAC address is randomized you might also want to prevent the > disclosure of your netvm's hostname to the network, since "sys-net" > might be a unique hostname (that links all your random MAC addresses and > the fact that you likely use qubes). > > To prevent the hostname leak via DHCP option (12): > - start the debian 9 template > - open the file /etc/dhcpd/dhclient.conf > - in line number 15 you should see "send host-name = gethostname();" > - comment (add "#" at the beginning) or remove that line and store the file > - reboot your netvm > > I tested the change via inspecting dhcp requests and can confirm that > the hostname is no longer included in dhcp requests. > Thanks. Added as a comment: https://github.com/QubesOS/qubes-issues/issues/938#issuecomment-292843628 - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJY6wEhAAoJENtN07w5UDAwdI8P/2+Rl5K73adR4MiQAACLDpZj jZl9YKskHKqBUMR+m0T2LkD2yw+cGpkOXiDjypTy2eYcsPqfbp0PZnggSK/9IpKM ZjIjOmoYkm6dfp81HJbz8pqmlf6v2fEZ8CaeHqV6kZnxzlq1aqwwVwtMfrRH2Lqm HMOA5Hlh+kCCysFC1DvoaJAOL+yv1HlC0lJsCtAVMw0pJadMxNXE8+JGywyeT1sY OJ+VqOcp9sCqVta/jeWbLx/WzIjqkkDPDtVhuC9KC5uu0pg8zv76ah+nBoSbO5dO Byvj91yMsCtaDFr684Yq8YlKJLFu2TSIBoUrh5/LHOPp1QYrpOTiSjSX1tTBAYd2 pk3Sid5XxoGabSPxMHT4VF0vCQktPp4WeXjy1oRAdTyZSjx8VF9oGrZQuFzP0Fey 2Zp4nYAKXjj5Ellf89ogxObiAqmZwyMCBerFfvSEnCrtWkxdMn+8s0b9pVf2ewNe mKKW5YxyDVCpSlSmiewkUzLtihOOC7rzOanTt72ZxEpF6uwEiT8vA6V6uuEJKQrv TkQaLaXB1UnSN7mxstRVu5gi53sX1n9znBbJLiQmNcRUv/+E63Uj1biP21caOqyZ zmiffOUSUc72dJvnNsCVz9sfygTHLUKVybn5QQ0oEl1Zt4yeeFY7Cq860uEqr5lQ a6JXYZkSDeL99PRgd61w =noLw -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/3c49d353-59f2-7917-9f16-e69a262b21fc%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: coldkernel status update
On 04/09/2017 09:49 AM, Patrick Schleizer wrote: > Reg Tiangha: >> Thanks for all the hard work! WillyPillow just pointed out to me today >> on the qubes-devel mail list that installing busybox and updating >> initramfs in Whonix is all you need to do to get it to boot with >> coldkernel, > busybox will be installed on Whonix 14 by default. > > https://github.com/Whonix/anon-meta-packages/commit/92c70963ed34953a81f8e53273453926b738ea18 > > On the other hand, what about adding busybox as a dependency to the > coldkernel Debian package? > > Cheers, > Patrick > It should probably also be added as a dependancy to qubes-kernel-vm-support as well since the script that needs it comes from that package. I know that the package is currently in current-testing at the moment, but is it too late to modify it to add busybox as a dependency? That way, if/when it gets pushed out to stable, anyone wanting to use it on a Whonix template won't have to do anything extra to get coldkernel or other local kernels to work on 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/oceuto%247n5%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] realized why I always lose sound in the vms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2017-04-05 22:55, Jean-Philippe Ouellet wrote: > On Wed, Apr 5, 2017 at 11:29 PM, cooloutacwrote: >> The sound mixer app I installed xfe in mutes things when I lower the volume >> all the way by accident. Never realized till now lol. I always have to go >> into dom0 alsamixer. >> >> Is there a better plugin to use? Does a new iso come with one by default >> now? > > This same exact bug keeps coming up again and again. See: > - https://github.com/QubesOS/qubes-issues/issues/2550 > - https://github.com/QubesOS/qubes-issues/issues/2117 > - https://github.com/QubesOS/qubes-issues/issues/2291 > - https://github.com/QubesOS/qubes-issues/issues/2321 > - https://groups.google.com/forum/#!msg/qubes-users/53TYf5GYkqY/ZU8i5v6JAwAJ > > This was fixed a while ago, but people don't get the fix because of > the limitations of updating dom0 by only updating the packages > installed there. When things get fixed in the installer, they don't > trickle down to existing systems, and we don't publish new release > ISOs except for on major releases. This means the default install is > often broken, and many people end up needing to independently solve > the same problems over and over. This is clearly not ideal, and IMO > the way in which we manage dom0 needs some rethinking. > > For this specific case I think we'd need a meta-package tracking which > packages are installed by the installer, and have the installer just > list that one and have deps of it be pulled in automatically. That > would let us update *which* packages are installed by default and have > that change affect existing installs. Then, as for actually putting > the new mixer in the panel, we'd probably need a %post section in a > relevant package or something. > Thanks for bringing this problem and solution to everyone's attention, JPO. I've created a tracking issue (which, I hope, properly captures both the problem and the proposed solution): https://github.com/QubesOS/qubes-issues/issues/2742 > IMO updating needs a better solution overall. I tried to start a > discussion about this here: > - https://groups.google.com/forum/#!topic/qubes-users/dCctVsf15dE/discussion > but it didn't go anywhere. > IMHO, the reason that thread didn't go anywhere was because it did not clearly identify a serious problem that needed to be solved or an enhancement that ought to be implemented. I think your message above does a much better job of doing both, and the older thread is clearer in light of it. - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJY6vy+AAoJENtN07w5UDAwwjwP/i2ZSxHafmddFvtfSesQ6CGs /jN6BJYrBOmfvHL9zH5vx29IVsYPLt2mUC+r7OCZKOO2EyIsvTdq3FoBKXNM/pUO LfArmni/iUPjEYcpliNacLJNOnoJvx2wRisLH4hPb7jEoLv0KfmPp+eYbkchyNVM 2HpIGw8Fzo/fCth0gt5sWIL7Yo/ld9QWLuAnRXaWhp0d5P9TACai/Qt0Cby+eN7A V7GPBAT0cvP3gPtkE56Tf+F6ibi+zxPaS99WteHWSkXv8D39lncYH3269X+D1vLr 2KXNCgfxh0WNmd65xmwFHlj6ulGhpg6bqmoshLZxkATSprjUXloF7KZuYZarcWpP OPE/gKnx+TQ1QuFbijMdw1Ph66sdKonc7MXc8pS6uJckE7iMNGJx37Lxv4ZmHk6z PfAyCoerad9XidxNt15PJQOGTh1VGkarGRVV+uRAM+SIpctJzAOlj87N6aEiWpHd Eeuv5ndJPFbmYPl8Ihua9/KGpl259I6x4uwDXxX8JxU28SzrrkpaW8MvlDX0mhqn l94wJiO/cCHEbInrY4lz3ri9I0FGRrRf6Fr1iSzGIC8IBn7M/vdMQ9PvO0BAUwAu nIm4zqlCSXL/21WPTP4PiB8kfVyTRFQqQ06rSSZaSDYeOA/138C2+lHhNGM7Lgfd 4h/9l5TtnEdsAmnrydQZ =hiil -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/57371712-fb11-f8b9-c53e-3738e9c12e5c%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: USB installer did not use existing EFI system partition on NVME drives
On Saturday, April 8, 2017 at 11:22:09 PM UTC-7, jay...@gmail.com wrote: > I am unsure if this is primarily an issue with Qubes or the Anaconda > installer. > > Issue observed while installing in UEFI mode. BIOS was set to use AHCI > (otherwise, the "nvme disk" is not reported to the installer or the live usb > I used to look at the disk contents). > > Manual partitioning does not appear to recognize an existing EFI partition on > an "nvme disk" (1) as an EFI partition (error message "No valid bootloader > target device found..." (2)). > Installing anyway results in no Qubes boot option on reboot. (3) > Running efibootmgr -v from a live usb reports a Qubes entry at VenHw (instead > of a HD). > > The laptop I used also had a non-nvme disk, and accepting automatic > partitioning put a new esp on that disk instead. The install completed > successfully with automatic partitioning. I have observed no issues with the > installed Qubes system so far. > > (1) the disk is reported as nvme0n1 during the manual parition process. > (2) "No valid bootloader target device found. See below for details. For a > UEFI installation, you must include an EFI system partition on a > GPT-formatted disk, mounted at /boot/efi" > (3) I am unsure if this is relevant, but the installation process does write > a "qubes" folder to the ESP partition on the nvme disk. On my first > installation attempt, the write was corrupted, and trying to read the files > through a live usb reported "fat_get_cluster: invalid cluster chain (i_pos > 0)". Later attempts did not result in such an error, though no attempt > resulted in a working Qubes boot option. I attempted installing the same Qubes image again using an nvme partition for /boot/efi. Though the installed system did not work initially, I was able to create a working entry for /boot/efi/xen.efi with efibootmgr. -- 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/702f1bff-2045-4876-bada-e8cd970a16b3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?
On Sunday, April 9, 2017 at 2:55:01 PM UTC-4, cooloutac wrote: > I gotta say the dvm template always gets messed up too. So i also only > consider it untrusted tasks now. but the vault vm is great imo. > > Maybe you should post in user devel the people there are not as noob as me. You type to much trash and you give nothing to the community. -- 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/d9663d11-aea1-461b-98cc-c6d4199ad8ea%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] for people using MAC randomization (debian 9 tmpl): you might want to avoid hostname leaks via DHCP too
Hi, if you setup MAC randomization via network manager in a debian 9 template as described here: https://www.qubes-os.org/doc/anonymizing-your-mac-address/ you still leak your hostname. Once your MAC address is randomized you might also want to prevent the disclosure of your netvm's hostname to the network, since "sys-net" might be a unique hostname (that links all your random MAC addresses and the fact that you likely use qubes). To prevent the hostname leak via DHCP option (12): - start the debian 9 template - open the file /etc/dhcpd/dhclient.conf - in line number 15 you should see "send host-name = gethostname();" - comment (add "#" at the beginning) or remove that line and store the file - reboot your netvm I tested the change via inspecting dhcp requests and can confirm that the hostname is no longer included in dhcp requests. -- 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/69a68b76-9f83-771f-da84-9448790cd4a9%40openmailbox.org. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
[qubes-users] i3 current state 2017 on Qubes 3.2
Hello, I tried to install i3 windows manager from current Qubes repository (non testing) and i3-settings-qubes package (before i3 started first time). And I have problems : - i3 wizard manager start, although i3-settins-qubes packed already on the system (is it correct behavior?) - Qubes VM-to-VM copy/paste key combinations does not work. - Right mouse key on the firefox (and other applications does not work). :( And how to use firefox without right mouse key on i3? - After some testing (clicking :) ) on next re-login i3 die: On the bottom of the screen it say that missing some dependence. -- 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/88913115-900d-66f1-b54b-2adf9c0cfebc%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Why is there no built-in nvidia driver support? aka GTX 980 issues
On Saturday, April 8, 2017 at 12:31:18 PM UTC-4, cooloutac wrote: > On Friday, April 7, 2017 at 2:51:11 AM UTC-4, sl98077 wrote: > > On Thursday, March 9, 2017 at 11:56:52 PM UTC-5, cooloutac wrote: > > > Just to add you won't get any benefit from the Nvidia card. Qubes only > > > uses it for desktop effects. the vms don;t have 3d rendering. > > > > > > It's not only about 3D rendering it has to do with users that want to also > > dual boot with a spare ssd, be a little mindful others have different > > obligations.. if Qubes wants to grow it needs to be readily available for > > all users. > > > dual booting another os? That would defeat the purpose. Qubes is for people > who want some exra security. not a cool tech experiment. You have this silly statement for everything, the person above this post has his methods and there are certainly others. -- 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/7b6abc83-9b6f-4a89-b9d7-ed30c507819e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?
I gotta say the dvm template always gets messed up too. So i also only consider it untrusted tasks now. but the vault vm is great imo. Maybe you should post in user devel the people there are not as noob as me. -- 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/80fb44b6-c024-4a74-a1ec-a94eb7243329%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] HDMI-related threats in Qubes OS
On Sun, Apr 9, 2017 at 9:42 AM, Vít Šestákwrote: > > * DDC (PIN 15+16) – needed for getting the resolution etc., present even in > current version of VGA. While there is some attack surface, it seems to be > rather small. Note that this is not strictly necessary for things to work though. Having the display device report its supported resolutions lets local config managers display a list of resolutions to choose from, but the VGA controller is free to just try to output whatever resolution it wants. The driver does not inform the display device of what resolution it is using via some out-of-band protocol, this information is trivially inferred by the number of pixel clocks between the front & back porches of the vsync & hsync signals. In 2017 you can't really damage devices by providing invalid signals (or I would have most definitely broken some things in the process of developing my own VGA controller), in practice the device usually just reports "signal out of range" or equivalent. Back-reporting via i2c is nice and convenient, but by no means required for things to work. You can just try best resolution you want, and if it doesn't work then keep trying others until it works. -- 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/CABQWM_DDJV1ORFeyDwabckwLZ9dYBWBbLeBZOuQCohV90vCuuA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Why is there no built-in nvidia driver support? aka GTX 980 issues
On Sat, 8 Apr 2017 09:31:18 -0700 (PDT) cooloutacwrote: > On Friday, April 7, 2017 at 2:51:11 AM UTC-4, sl98077 wrote: > > On Thursday, March 9, 2017 at 11:56:52 PM UTC-5, cooloutac wrote: > > > Just to add you won't get any benefit from the Nvidia card. > > > Qubes only uses it for desktop effects. the vms don;t have 3d > > > rendering. > > > > > > It's not only about 3D rendering it has to do with users that want > > to also dual boot with a spare ssd, be a little mindful others have > > different obligations.. if Qubes wants to grow it needs to be > > readily available for all users. > > > dual booting another os? That would defeat the purpose. Qubes is for > people who want some exra security. not a cool tech experiment. > Using a Sata Switch that plugs in a PCI slot, one can turn on/off different drives, allowing dual booting without diminishing the security. I ordered this one (still waiting for it): http://thumbs.ebaystatic.com/images/g/ZBgAAOSwvg9XbqSI/s-l225.jpg -- 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/20170409152437.5c1ed303%40zoho.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: off topic - invite codes to 'riseup'
I too need two invite codes. Thanks in advance. :) On Tuesday, October 28, 2014 at 11:56:49 PM UTC+5:30, bm-2cu9wcijafoqtf6...@bitmessage.ch wrote: > Dear qubes-users, > > I am long time qubes follower and user. I apologize in advance if anyone > feels this request is spam. > > I am looking for two invite codes needed to sign up to anonymous > riseup.net email service. > > I am hoping there are some qubes users who are riseup.net account > holders. > > Can anyone please send me a couple of invite codes that I might be able > to sign up? > > Thank you in advance. -- 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/a4a6eda4-3e75-4113-961b-96c77fee5682%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: coldkernel status update
Reg Tiangha: > Thanks for all the hard work! WillyPillow just pointed out to me today > on the qubes-devel mail list that installing busybox and updating > initramfs in Whonix is all you need to do to get it to boot with > coldkernel, busybox will be installed on Whonix 14 by default. https://github.com/Whonix/anon-meta-packages/commit/92c70963ed34953a81f8e53273453926b738ea18 On the other hand, what about adding busybox as a dependency to the coldkernel Debian package? Cheers, Patrick -- 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/587f68f5-a342-b55a-6b39-4d5cd555c255%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] HDMI-related threats in Qubes OS
Well, there seems to be a cheaper way to do roughly the same. In a nutshell, you just ensure there is no wire for those two things: * HEAC+ (audio return channel plus ethernet). HEAC+ is optional and thus safe to remove. * CEC (remote control input) – This one is a bit more tricky. While CEC is also optional, its wiring is reportedly (via Wikipedia) mandatory. I haven't found this in specification. Maybe CEC wire is mandatory for cables (as this is in 1.0 specification), but can be completely ignored in both parties. Theoretically, the worst what can (but hopefully won't) happen is downgrade to single-link digital DVI, effectively restricting the resolution to 1920 × 1200 @ 60 Hz, see below. OTOH, if you don't want to cut CEC, my brief look suggests just minimal attack surface. Removing them will keep only two inputs you can hardly get rid of: * DDC (PIN 15+16) – needed for getting the resolution etc., present even in current version of VGA. While there is some attack surface, it seems to be rather small. * HotPlug/HEAC- (PIN 19) – I believe it will work just as hotplug detection if HEAC+ is missing. So, virtually no attack surface. How to practically cut the wire(s)? You don't have to actually cut the cable etc. There are few easy options: a. Use HDMI-to-DVI and then DVI-to-HDMI, both should be passive converters. According to pinout at http://pinouts.ru/visual/gen/hdmi_dvi_cable.jpg , it seems to cut just the two input wires, i.e., it would do exactly what we want. While this looks like converting to single-link DVI and back, passive converters will probably allow full HDMI without the features we want to get rid of. b. Use an older cable without HEAC+ wire. According to the specification, they should exist, but I am not sure if you can find a new one. Useful for home TV, since it is you who buys the cable. However, such cable will probably still have CEC. On the other hand, brief look at CEC does not suggest a large attack surface there. c. Use cable without CEC wire. It is probably nonstandard, but it seems to actually exist: https://www.pulse-eight.com/p/110/cec-less-hdmi-cable. It is not sure if the cable includes HEAC+ wire ir not. I suggest verifying the wiring by ohmmeter. “Cutting” wires might be also better from security perspective than proxy, but it depends. When the proxy is implemented carefully, it might even absorb attack surface of DDC. It also could protect the device (e.g., Smart TV) from attacks from compromised laptop, but this is probably slightly off this topic. ## Should Qubes handle this? I believe that Qubes should care about it partialy, but the developers cannot do all for you. First, QubesOS should ignore HDMI ethernet and maybe some other inputs (CEC and ARC) from HDMI. Maybe it already ignores all network devices connected to dom0, but I haven't seen anything that confirms this. Failure to ignore HDMI network in dom0 could make QubesOS more vulnerable to attacks over HDMI than conventional distros are, especially when dom0 is based on EOLed Fedora version. On the other hand, QubesOS probably cannot resolve this exposure in full extent. Imagine an input being processed by GPU firmware and then with GPU driver and then rejected by QubesOS. You see, the rejection by QubesOS does not necessarily prevent processing of the input by some parsers running with absolute privileges, either dom0 or DMA-enabled device handled by dom0. QubesOS will hardly fix them and I consider it to be outside of QubesOS responsibilities. Regards, Vít Šesták 'v6ak' -- 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/f445bbc5-cd0f-4dab-ad51-2032c2d55736%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Windows 7 installation stops
Hello, What version of Qubes and which Windows 7 version (home/pro/32bit/64bit) are you using? I've successfully installed Windows 7 on Qubes 3.1 and 3.2 Make sure to add at least 2GB RAM to the windows VM. Following the excellent Qubes Documentation I found out that if you create a Windows HVM from the command line it has only 512 MB RAM which caused problems after (!) installation. Be also sure to use the 32bit-Version of Windows. I have used Windows 7 Pro 32bit and installation was smooth & easy. If you need further help, do not hesitate to contact me. Regards - P. Am 09.04.2017 4:45 vorm. schrieb "'01v3g4n10' via qubes-users" < qubes-users@googlegroups.com>: On Tuesday, April 4, 2017 at 6:10:44 AM UTC-5, pete...@hushmail.com wrote: > Hi > I can't install HVM with Windows 7 because the installation stops on the screen "Starting Windows". Before this I had installed and removed it many times. What can be succeeded? I have no problems with win8 or linux OS. > > Best https://github.com/QubesOS/qubes-issues/issues/2488 -- 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/8aefeec8-b4be-4328-9913-792a2238d45e%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/CAM8xnvL%3DrX13H_M8-un2QwZz81VK9dOcqCOStbKGtKJah2NR%2Bw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Simple Dom0 password manager for an imperfect-but-strong security upgrade?
>usability is not a good reason to add or change anything. I suggest you switch to running Lynx on OpenBSD then. I guarantee you're running all kinds of horribly insecure stuff on whatever you're using to read this right now. Usability has always been a top priority in Qubes and that is a major part of why it is such an excellent operating system. Why on Earth do you think they bothered making a GUI tool? Why don't they require a password for sudo? (Newcomers: that last one was a rhetorical question that I've already analyzed at length; please see older messages om this thread.) >Yes i'm a noob, but you still sound like a security nightmare to me. Security isn't a gut feeling thing. At least, not in the way you're doing it. Your gut needs to know what it's talking about first. > You lost me way earlier when you mentioned browser extensions Exactly my point. You don't understand at all what the purpose of the browser extension is. All it does is generate a token that Dom0 uses to look up something in its index. If you can't follow me trying to explain what the extension does (it generates a token of about 3 characters according to a specific set of rules, and appends them to the page title. That's it!), let me try instead to explain what it DOESN'T do: A. The extension would have no way of knowing if the Dom0 code was actually doing anything with a particular token. It wouldn't know if the Dom0 code was running. It wouldn't know whether or not the Dom0 tool was even installed. B. As per the above, it would receive no feedback or input from Dom0. C. It wouldn't be involved at all in handling the username / password (although I guess someone could write another extension to automate that as well. But this probably wouldn't be high on my list of priorities.) D. At no point would the extension cause any data whatsoever to be written to any files in Dom0 except perhaps in the form of a logfile (which the extension itself isn't aware of or capable of accessing.) E. At no point is the extension concerned with the keypress that activates the tool. It doesn't know or care when or how any of that stuff happens. It keeps providing index tokens all day long even if the password key combo is never pressed. F. It would be entirely optional. The password tool could function just fine without it, but would be vulnerable to a title spoofing attack (not as dire a threat as M. Ouellet thinks, but it's there) and it would require a bit more effort to set up your password list on Dom0 and keeping it running smoothly. G. The extension should be thought of as an *extra layer of armor*, not an extra point of failure in this setup. If someone exploits a bug that causes the extension to crash or behave erratically, the tool on Dom0 immediately stops providing passwords. It *can't* provide any passwords if it's been set up to use the tokens but they aren't being provided. H. Building on G, if someone manages to compromise your entire web browser such that they can either disable the extension (or control it) AND they can read your randomly generated salt... then yes, they could intercept your passwords on that VM. And this is what they could do in any other situation involving a catastrophic browser takeover. But you're better off in this situation vs. using the browser's built-in password manager, even an encrypted one. Vs. manually copy and pasting passwords from an offline VM, and it's roughly the same situation. I. Mistakes and misconfiguration should just result in nothing at all happening. Pressing the activation key for the tool while you're on the wrong site results in nothing happening except perhaps an error popup (that is handled by the Dom0 tool, not the extension.) > If my Mother can handle ctrl shift c, I'm sure you can too. This is akin to telling Joanna that your mother can handle running 5 different VMs in Virtualbox, so she can too--crazy window mixing from different VMs? OMG! That's a security nightmare! You've no idea what you're talking about, and Ouellet refuses to consider the version with an extension because he knows there is no plausible security hole. He doesn't like it because it's messy, and I agree, but open source software has rarely been driven forward by anything but people giving in and hacking together something kinda messy. Messy doesn't mean full of security holes, it just means... messy. And if you're telling me you use manual copy/pasting for everything, and you don't use persistent cookies, and you use a DispVM[1] for everything that requires a login, and you don't use a password manager, AND you have strong randomized passwords for everything, AND you have more than a couple dozen accounts, AND that you use your computer heavily, with a decent amount of DispVM restarts throughout the day... Well, I don't believe you. Nobody who tried use to do it all manually, with heavy usage over a prolonged period
[qubes-users] USB installer did not use existing EFI system partition on NVME drives
I am unsure if this is primarily an issue with Qubes or the Anaconda installer. Issue observed while installing in UEFI mode. BIOS was set to use AHCI (otherwise, the "nvme disk" is not reported to the installer or the live usb I used to look at the disk contents). Manual partitioning does not appear to recognize an existing EFI partition on an "nvme disk" (1) as an EFI partition (error message "No valid bootloader target device found..." (2)). Installing anyway results in no Qubes boot option on reboot. (3) Running efibootmgr -v from a live usb reports a Qubes entry at VenHw (instead of a HD). The laptop I used also had a non-nvme disk, and accepting automatic partitioning put a new esp on that disk instead. The install completed successfully with automatic partitioning. I have observed no issues with the installed Qubes system so far. (1) the disk is reported as nvme0n1 during the manual parition process. (2) "No valid bootloader target device found. See below for details. For a UEFI installation, you must include an EFI system partition on a GPT-formatted disk, mounted at /boot/efi" (3) I am unsure if this is relevant, but the installation process does write a "qubes" folder to the ESP partition on the nvme disk. On my first installation attempt, the write was corrupted, and trying to read the files through a live usb reported "fat_get_cluster: invalid cluster chain (i_pos 0)". Later attempts did not result in such an error, though no attempt resulted in a working Qubes boot option. -- 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/2101ef84-7a2a-4b4b-8cbd-75ed282e855b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.