[qubes-users] Secure Handling of Encrypted Drives
I am trying to figure out a way to securely handle my encrypted drives without two things: connecting the USB directly to the Vault (as this is obviously a bad idea for security), and decrypting the USB in sys-usb (also obviously a bad idea). As an example, I have some USB that I keep encrypted backups of my important documents that I keep with me in case an emergency happens (which now that I am using Qubes will probably also be in the Vault). I have files on there that I need to move to Vault, and I need to be able to continue to put files onto it (whether from Vault or from a scan I have done.Which I know is a whole different problem; so I want to focus on just the encrypted storage. Another example is my backup drives which are all encrypted, and that I would like to have access to for the standard reasons. I have been pointed to [1] a couple days ago by JPO and I believe this is part of the soution, but not the whole thing. My two solutions that I have thought through are: doing PCI patthrough directly to the Vault (which is the least favorite of my ideas), and creating a separate VM for encryption that only houses software for encrypting and decrypting (dm-crypt or veracrypt). This way the USB will be passed through to this VM and will never directly touch the Vault (except through qvm-move-to-vm). I had a third solution of adding this functionality to DispVMs, but I can't PCI pass the USB to the DispVMs when they are running. So that one is out. Thanks in advance for the help; can't wait to see what I missed! [1] https://github.com/rustybird/qubes-split-dm-crypt -- Respectfully, Sam Hentschel FD6A 2998 5301 B440 D26B 7040 69D1 CE58 6FA5 BB5A -- 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/20170412031247.GA989%40Personal-Email. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
[qubes-users] Re: Breaking the Security Model of Subgraph OS
Nice will def read this! As far as I know only diff between doing it yourself is they have their own sandbox or something and everything is sandboxed that needs network? And write a couple programs from scratch like a mail client? I can't remember, I tried it out very briefly and didn't like it... I think I remember installing htop and seeing root processes and that took me by surprise thinking it was supposed to have hardcore kernel restrictions. Then I think I was asking some questions of the developers on irc and didn't take it seriously or trust 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/cc91ad7d-7146-454b-9ef9-3225310e1a07%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Breaking the Security Model of Subgraph OS
What exactly makes subgraph special and not just another apparmor/selinux MAC type clone? The firewall is a neat bit of progress however, but again that can also be accomplished with an apparmor MAC default profile however allow app to access site etc is only on an IP basis not a DNS basis (dns basis is sketchy anyways). The "firewall not designed for malicious apps" is silly, a calculator or anything for that matter should not be accessing the internet without permission - period - however did we live life before everything even our toaster was connected to the internet to retrieve optimal toasting parameters. -- 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/732dcf03-f12b-44aa-0419-5cf21269e47a%40gmx.com. 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
On Tue, Apr 11, 2017 at 06:20:38AM -0700, Dominique St-Pierre Boucher wrote: > On Monday, April 10, 2017 at 5:06:30 PM UTC-4, qubenix wrote: > > qubenix: > > > Andrew David Wong: > > >> 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 > > >> > > >> > > > > > > Nice. I was just thinking about this after spending some time on my > > > routers interface. Thanks for the post! > > > > > > > After testing this, 'sys-net' still shows up on my router interface. > > > > -- > > qubenix > > GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 > > Did the same test and got the same result. > > Anyone has a solution? I can always change my hostname for something else, > but I would prefer not sending the hostname or finding a way to randomize > it!!! > > Dominique > Strange, because those instructions are standard for removing the hostname - I set it as blank, rather than commenting out. If you sniff the traffic you will see that the hostname is indeed no longer sent. Why is it on your router interface? My guess is that your router is returning the hostname that it has associated with the MAC address. I've seen this happen when changing hostname, and the DHCP server returns the *old* hostname as part of the DHCP exchange. If you reboot the router and test again, you may find that the issue goes away. You could, of course, set a random hostname from rc.local on each boot of sys-net. 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/20170411232447.GA18085%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Stripping down dom0 kernels: Any tips?
So I've been playing around with kernels in Qubes and successfully run kernel 4.10 in dom0 and any domUs where grsecurity-based kernels create too many issues. My next goal is to try and see if I can get coldkernel running in dom0 alongside the Qubes-specific kernel patches. I had tried a couple of months ago, but my machine kernel panicked and I ran out of time before I had to get back to work on other things so I stopped my trials. I realized that the grsecurity patches can be configured for either a VM host or a guest, and I had previously only been compiling guest kernels and used that kernel.config to build my dom0 test kernel. I've been trying to avoid having to compile things twice, but if it not being a host kernel was why I was having issues, then maybe there is no choice but to have two separate kernel configs. So if that's the case and I have to compile a separate dom0 kernel with its own configuration anyway, I might as well go all the way. I already customize my kernels for my specific hardware (for example, I strip away all of the AMD CPU specific stuff because I only run Intel hardware, and take out some drivers for hardware that I don't have or will never use, etc), but I'm thinking I can go much further for a dom0 kernel. I'm talking about stripping away things like the TCP/IP stack, netfilter, every single hardware driver outside of disk, graphics, and keyboard/mouse, and maybe a few other things too. The question I had was about Xen since I'm not as familiar with it as I am with building kernels in general: How much does Xen need in dom0 in order to work with the hardware? For example, since sys-net has my wifi drivers, can I remove wifi driver support in the dom0 kernel? Or does Xen need a driver for it in order to pass it along to sys-net? Same kind of question for keyboard/mouse; if I have a sys-usb VM, could I theoretically strip away all USB drivers from the dom0 kernel? I'm thinking I'd at least need USB keyboard in order to input the disk passphrase on boot and could probably ditch everything else, but maybe not? I'll probably start playing around with seeing how far I can cut down the dom0 kernel this weekend, but figured in the meantime I'd ask the list if they have any advice or tips if they've tried something like this in the past. -- 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/ocjlbv%24std%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Persistent /usr/local: Are there risks?
On 04/10/2017 05:54 PM, Unman wrote: On Mon, Apr 10, 2017 at 03:39:26PM -0400, Chris Laprise wrote: On 04/10/2017 03:17 PM, Chris Laprise wrote: On 04/10/2017 02:55 PM, Reg Tiangha wrote: I think I'll try an /etc/rc.local script that deletes /rw/usrlocal and re-creates just the top dir. Also /rw/config and /rw/bind-dirs. Pretty much the only persistent thing left would be contents of /rw/home, which is sort of a middle of the road between fully persistent /rw and using dispVMs for everything. And it's set in the template - so if you don't want it open the template, remove the symlink and move /usr/local.orig to /usr/local. Then qubes based on that template wont have persistent /usr/local. NB this will break torVMs and maybe other features of your Qubes. An alternative approach would be to run tripwire against persistent directories and monitor changes. unman I think an exception can be carved out for Whonix/tor VMs without too much trouble. Currently, the script can make exceptions based on dir/files stored under /etc/default/vms/vm-name. But a more general exception for this type of VM would be preferable in this case. -- Chris Laprise, tas...@openmailbox.org 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/32e12404-7a57-541d-cdef-e3a239b29bfa%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Protect AppVM init startup scripts:
On 04/11/2017 12:14 PM, cooloutac wrote: On Monday, April 10, 2017 at 11:43:55 AM UTC-4, Chris Laprise wrote: Here is a small script for Linux templates that protects files executed on startup by... bash sh Gnome KDE Xfce X11 Together with enabling sudo authentication, this is a simple way to make template-based VMs less hospitable to malware. LINK: https://github.com/tasket/Qubes-VM-hardening -- Chris Laprise, tas...@openmailbox.org https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 ok you convinced me I have to enable sudo now. lol I should mention this approach for /home init scripts does also help standalone Linux VMs. There is an update in the works that can knock-out even some root-user (privilege escalation) malware, though this addition would not help standalones. The technique is to erase-or-replace dirs like /rw/config at boot time. The overall result should be that an attacked VM (especially template-based) has a better chance of malware being in a dormant/disabled state when the VM is started. And the price in users' time/energy for gaining this margin of security should be quite low. -- Chris Laprise, tas...@openmailbox.org 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/6848aa14-4b90-91e9-dfbf-77037cd9cb04%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] HCL - Samsung 940X3G hcl report text
--- layout: 'hcl' type: 'laptop' hvm: 'yes' iommu: 'no' slat: 'yes' tpm: 'unknown' brand: | SAMSUNG ELECTRONICS CO., LTD. model: | 940X3G/930X3G bios: | P05ACJ.128.140819.dg cpu: | Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz cpu-short: | FIXME chipset: | Intel Corporation Haswell-ULT DRAM Controller [8086:0a04] (rev 09) chipset-short: | FIXME gpu: | Intel Corporation Haswell-ULT Integrated Graphics Controller [8086:0a16] (rev 09) (prog-if 00 [VGA controller]) gpu-short: | FIXME network: | Intel Corporation Wireless 7260 (rev 6b) Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c) memory: | 8106 scsi: | TOSHIBA THNSNH25 Rev: N103 versions: - works: 'FIXME:yes|no|partial' qubes: | R3.2 xen: | 4.6.4 kernel: | 4.4.38-11 remark: | FIXME credit: | FIXAUTHOR link: | FIXLINK --- -- 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/e708c1aab493513c681b894601f02da9%40etstv.com. For more options, visit https://groups.google.com/d/optout. --- layout: 'hcl' type: 'laptop' hvm: 'yes' iommu: 'no' slat: 'yes' tpm: 'unknown' brand: | SAMSUNG ELECTRONICS CO., LTD. model: | 940X3G/930X3G bios: | P05ACJ.128.140819.dg cpu: | Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz cpu-short: | FIXME chipset: | Intel Corporation Haswell-ULT DRAM Controller [8086:0a04] (rev 09) chipset-short: | FIXME gpu: | Intel Corporation Haswell-ULT Integrated Graphics Controller [8086:0a16] (rev 09) (prog-if 00 [VGA controller]) gpu-short: | FIXME network: | Intel Corporation Wireless 7260 (rev 6b) Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c) memory: | 8106 scsi: | TOSHIBA THNSNH25 Rev: N103 versions: - works: 'FIXME:yes|no|partial' qubes: | R3.2 xen: | 4.6.4 kernel: | 4.4.38-11 remark: | FIXME credit: | FIXAUTHOR link: | FIXLINK ---
[qubes-users] HCL - Samsung 940X3G hcl report
--- layout: 'hcl' type: 'laptop' hvm: 'yes' iommu: 'no' slat: 'yes' tpm: 'unknown' brand: | SAMSUNG ELECTRONICS CO., LTD. model: | 940X3G/930X3G bios: | P05ACJ.128.140819.dg cpu: | Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz cpu-short: | FIXME chipset: | Intel Corporation Haswell-ULT DRAM Controller [8086:0a04] (rev 09) chipset-short: | FIXME gpu: | Intel Corporation Haswell-ULT Integrated Graphics Controller [8086:0a16] (rev 09) (prog-if 00 [VGA controller]) gpu-short: | FIXME network: | Intel Corporation Wireless 7260 (rev 6b) Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c) memory: | 8106 scsi: | TOSHIBA THNSNH25 Rev: N103 versions: - works: 'FIXME:yes|no|partial' qubes: | R3.2 xen: | 4.6.4 kernel: | 4.4.38-11 remark: | FIXME credit: | FIXAUTHOR link: | FIXLINK --- -- 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/3fdd4aa2b78e7601e820f96c604d4205%40etstv.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] HCL - Samsung 940X3G
-- 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/73debf7e591a4779a772706a4c3a4e08%40etstv.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Display issues with Kali HVM
When I install Kali in an HVM it has this terrible display issue [1]. When I move the mouse to the top-left of the window, I can see the cursor navigate over the Application menu in the bottom left. Does anyone know how to fix this? This screen resolution trick [2] doesn't do it. If I set a custom xorg.conf with these changes, GNOME fails to load when I try logging in, and I get spit back out at the login screen. I know that I can follow instructions here [3] and use katoolin to make a Debian template full of Kali tools, but I'm hoping to actually run Kali itself, with GNOME configured exactly as it is. [1] https://i.imgur.com/pLWGnmw.png [2] https://www.qubes-os.org/doc/linux-hvm-tips/#screen-resolution [3] https://www.qubes-os.org/doc/pentesting/kali/ -- 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/32f4ec03-555d-0cf4-1f5f-eb7bd5e69f85%40micahflee.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Breaking the Security Model of Subgraph OS
I met up with Joanna at the recent Tor meeting in Amsterdam, and we tried to see if we could hack Subgraph OS, which I was running on my travel computer. We succeeded, and I've written up all the details here: https://micahflee.com/2017/04/breaking-the-security-model-of-subgraph-os/ And also made a video of the exploit here: https://www.youtube.com/watch?v=SVsllZ7g7-I The analysis compares how Qubes would handle such an attack. -- 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/b8638f35-6c0c-2d9a-e321-5b951facc8e3%40micahflee.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: USB Headset
W dniu wtorek, 11 kwietnia 2017 18:25:09 UTC+2 użytkownik Stephan Marwedel
napisał:
> Thank you for the hints. When assigning the USB controller to the
> Windows HVM not error messages are displayed anymore. BTW, it is
> difficult to figure out which USB controller to assign to the Windows HVM.
>
> However, the USB headset does not appear as a device in Windows, so the
> appropriate driver is not installed and I cannot assign it as
> input/output device in my conferencing software. Do I need anything on
> the Windows side as well? Is it necessary to install the Qubes Windows
> Tools to have USB audio functionalty? I do not have them installed
> currently.
>
>
> On 03.04.17 20:46, Grzesiek Chodzicki wrote:
> > W dniu poniedziałek, 3 kwietnia 2017 20:45:19 UTC+2 użytkownik Stephan
> > Marwedel napisał:
> >> I tried to configure my system like described below. I stopped the
> >> sys-usb VM and assigned the USB controller to which the headset is
> >> connected to the Windows HVM. When trying to start it the following
> >> error appears:
> >>
> >>--> Loading the VM (type = HVM)...
> >> Traceback (most recent call last):
> >> File "/usr/bin/qvm-start", line 136, in
> >> main()
> >> File "/usr/bin/qvm-start", line 120, in main
> >> xid = vm.start(verbose=options.verbose,
> >> preparing_dvm=options.preparing_dvm, start_guid=not options.noguid,
> >> notify_function=tray_notify_generic if options.tray else None)
> >> File
> >> "/usr/lib64/python2.7/site-packages/qubes/modules/01QubesHVm.py", line
> >> 335, in start
> >> return super(QubesHVm, self).start(*args, **kwargs)
> >> File
> >> "/usr/lib64/python2.7/site-packages/qubes/modules/000QubesVm.py", line
> >> 1966, in start
> >> self.libvirt_domain.createWithFlags(libvirt.VIR_DOMAIN_START_PAUSED)
> >> File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1059, in
> >> createWithFlags
> >> if ret == -1: raise libvirtError ('virDomainCreateWithFlags()
> >> failed', dom=self)
> >> libvirt.libvirtError: internal error: Unable to reset PCI device
> >> :00:14.0: no FLR, PM reset or bus reset available
> >>
> >> I tried to connect the headet to a different USB controller and assign
> >> that to the Windows HVM to no avail:
> >>
> >> --> Loading the VM (type = HVM)...
> >> Traceback (most recent call last):
> >> File "/usr/bin/qvm-start", line 136, in
> >> main()
> >> File "/usr/bin/qvm-start", line 120, in main
> >> xid = vm.start(verbose=options.verbose,
> >> preparing_dvm=options.preparing_dvm, start_guid=not options.noguid,
> >> notify_function=tray_notify_generic if options.tray else None)
> >> File
> >> "/usr/lib64/python2.7/site-packages/qubes/modules/01QubesHVm.py", line
> >> 335, in start
> >> return super(QubesHVm, self).start(*args, **kwargs)
> >> File
> >> "/usr/lib64/python2.7/site-packages/qubes/modules/000QubesVm.py", line
> >> 1958, in start
> >> nd.dettach()
> >> File "/usr/lib64/python2.7/site-packages/libvirt.py", line 5249, in
> >> dettach
> >> if ret == -1: raise libvirtError ('virNodeDeviceDettach() failed')
> >> libvirt.libvirtError: Requested operation is not valid: PCI device
> >> :00:1d.0 is in use by driver xenlight, domain AIB
> >>
> >> What did I miss in my configration? I have VT-d and VT-x enabled (I'm on
> >> a i7-3520M CPU).
> >>
> >> On 04/02/2017 12:19 AM, Grzesiek Chodzicki wrote:
> >>> W dniu sobota, 1 kwietnia 2017 18:20:40 UTC+2 użytkownik Stephan Marwedel
> >>> napisał:
> Dear Qubes user community,
>
> I want to use a USB headset (Jabra Evolve) for the purpose of using my
> laptop as a replacement for a desktop phone. Is that possible with
> Qubes? If so, what are the settings I need to tweak for that?
>
> Can I use it also inside a Windows HVM to enable the use of proprietary
> conferencing software from Cisco? I have tried it using a Windows VM
> with VirtualBox on CentOS 7. That worked, although the audio quality is
> pretty bad. Do I need special settings for my Windows HVM in order to
> use the headset?
>
> Regards,
> Stephan
> >>> I did a similar thing with my sound card that requires proprietary
> >>> Windows only drivers to operate.
> >>> First, check whether VT-d is available and enabled on your laptop with xl
> >>> dmesg|grep VT-d
> >>> Second, identify the number of available USB controllers with sudo
> >>> lspci|grep USB. If you have more than one controller, assign it to
> >>> Windows HVM.
> >>> Within Windows HVM install USB controller driver (if it's a USB 3.0 or
> >>> later) and then install drivers for the headset (if required).
> >>> I am able to use the soundcard in the Windows HVM with no problems so you
> >>> should too. Remember to enable VT-d in BIOS/UEFI first.
> >>>
> > run qvm-pci -s sys-usb pci_strictreset false then reboot the physical
> > machine and try again
You need to install the USB controller
Re: [qubes-users] Re: USB Headset
Thank you for the hints. When assigning the USB controller to the
Windows HVM not error messages are displayed anymore. BTW, it is
difficult to figure out which USB controller to assign to the Windows HVM.
However, the USB headset does not appear as a device in Windows, so the
appropriate driver is not installed and I cannot assign it as
input/output device in my conferencing software. Do I need anything on
the Windows side as well? Is it necessary to install the Qubes Windows
Tools to have USB audio functionalty? I do not have them installed
currently.
On 03.04.17 20:46, Grzesiek Chodzicki wrote:
W dniu poniedziałek, 3 kwietnia 2017 20:45:19 UTC+2 użytkownik Stephan Marwedel
napisał:
I tried to configure my system like described below. I stopped the
sys-usb VM and assigned the USB controller to which the headset is
connected to the Windows HVM. When trying to start it the following
error appears:
--> Loading the VM (type = HVM)...
Traceback (most recent call last):
File "/usr/bin/qvm-start", line 136, in
main()
File "/usr/bin/qvm-start", line 120, in main
xid = vm.start(verbose=options.verbose,
preparing_dvm=options.preparing_dvm, start_guid=not options.noguid,
notify_function=tray_notify_generic if options.tray else None)
File
"/usr/lib64/python2.7/site-packages/qubes/modules/01QubesHVm.py", line
335, in start
return super(QubesHVm, self).start(*args, **kwargs)
File
"/usr/lib64/python2.7/site-packages/qubes/modules/000QubesVm.py", line
1966, in start
self.libvirt_domain.createWithFlags(libvirt.VIR_DOMAIN_START_PAUSED)
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1059, in
createWithFlags
if ret == -1: raise libvirtError ('virDomainCreateWithFlags()
failed', dom=self)
libvirt.libvirtError: internal error: Unable to reset PCI device
:00:14.0: no FLR, PM reset or bus reset available
I tried to connect the headet to a different USB controller and assign
that to the Windows HVM to no avail:
--> Loading the VM (type = HVM)...
Traceback (most recent call last):
File "/usr/bin/qvm-start", line 136, in
main()
File "/usr/bin/qvm-start", line 120, in main
xid = vm.start(verbose=options.verbose,
preparing_dvm=options.preparing_dvm, start_guid=not options.noguid,
notify_function=tray_notify_generic if options.tray else None)
File
"/usr/lib64/python2.7/site-packages/qubes/modules/01QubesHVm.py", line
335, in start
return super(QubesHVm, self).start(*args, **kwargs)
File
"/usr/lib64/python2.7/site-packages/qubes/modules/000QubesVm.py", line
1958, in start
nd.dettach()
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 5249, in
dettach
if ret == -1: raise libvirtError ('virNodeDeviceDettach() failed')
libvirt.libvirtError: Requested operation is not valid: PCI device
:00:1d.0 is in use by driver xenlight, domain AIB
What did I miss in my configration? I have VT-d and VT-x enabled (I'm on
a i7-3520M CPU).
On 04/02/2017 12:19 AM, Grzesiek Chodzicki wrote:
W dniu sobota, 1 kwietnia 2017 18:20:40 UTC+2 użytkownik Stephan Marwedel
napisał:
Dear Qubes user community,
I want to use a USB headset (Jabra Evolve) for the purpose of using my
laptop as a replacement for a desktop phone. Is that possible with
Qubes? If so, what are the settings I need to tweak for that?
Can I use it also inside a Windows HVM to enable the use of proprietary
conferencing software from Cisco? I have tried it using a Windows VM
with VirtualBox on CentOS 7. That worked, although the audio quality is
pretty bad. Do I need special settings for my Windows HVM in order to
use the headset?
Regards,
Stephan
I did a similar thing with my sound card that requires proprietary Windows only
drivers to operate.
First, check whether VT-d is available and enabled on your laptop with xl
dmesg|grep VT-d
Second, identify the number of available USB controllers with sudo lspci|grep
USB. If you have more than one controller, assign it to Windows HVM.
Within Windows HVM install USB controller driver (if it's a USB 3.0 or later)
and then install drivers for the headset (if required).
I am able to use the soundcard in the Windows HVM with no problems so you
should too. Remember to enable VT-d in BIOS/UEFI first.
run qvm-pci -s sys-usb pci_strictreset false then reboot the physical machine
and try 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/9d993bd1-5af5-2a36-02e8-b4b4b013cdbd%40tu-ilmenau.de.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] HDMI-related threats in Qubes OS
On Monday, April 10, 2017 at 3:28:05 PM UTC-4, Vít Šesták wrote: > > what about vga or dvi wires? > > Frankly, my main interest is HDMI. But I have briefly looked at VGA and DVI > pinouts. It seems that the only input channels are hotplug (if you count > this) and DDC (for resolutions etc.). Plus older VGA seems to have some > pre-DDC mechanism called “Monitor ID”. For VGA, you can see scheme > http://pinouts.ru/Video/VGA15_pinout.shtml . The “Dir” column is helpful, > though it seems to be incorrect at line “I2C bidirectional data line”. > > > Qubes already ignores hdmi sound driver in my case lol. > > Well, I am not sure if this is intentional, but I don't think so. > > > Because really how can we even trust its hardware, its another separate pc > > outside of qubes. > > Well, you do trust you hardware at some degree. Without trusted HW, you > cannot trust it runs the SW properly and it does not spy you in other means, > e.g., by sending screen content somewhere. Malware in a compromised digital > TV could do so and neither Qubes nor cut wires can prevent it. But maybe you > decide to trust the TV just partially (e.g., public presentation), so you > don't read top-secret messages etc. here. > > > Same goes for printers if you using it, you already giving up some > > privacy regardless of Qubes. > > Mostly true, but a bit vague. But the situation is the same as with monitors > – choose your level of trust and then behave accordingly. > > Regards, > Vít Šesták 'v6ak' yes exactly. -- 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/dbf2f0d5-7198-41eb-babb-425ad4be0d48%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Persistent /usr/local: Are there risks?
On Monday, April 10, 2017 at 5:54:27 PM UTC-4, Unman wrote: > On Mon, Apr 10, 2017 at 03:39:26PM -0400, Chris Laprise wrote: > > On 04/10/2017 03:17 PM, Chris Laprise wrote: > > >On 04/10/2017 02:55 PM, Reg Tiangha wrote: > > > > > >I think I'll try an /etc/rc.local script that deletes /rw/usrlocal and > > >re-creates just the top dir. Also /rw/config and /rw/bind-dirs. Pretty > > >much the only persistent thing left would be contents of /rw/home, which > > >is sort of a middle of the road between fully persistent /rw and using > > >dispVMs for everything. > > > > > > > > >> > > >>I'm definitely going to apply your scripts to my TemplateVMs soon now > > >>that I've been made aware, but I wish there were a way to turn off > > >>persistent /usr/local and to make AppVMs use the TemplateVM's version > > >>instead. I don't use the feature, so I would prefer that /usr/local gets > > >>wiped every time like everything else in the root file system since > > >>that's the behaviour I expected to happen when I first started using > > >>Qubes (I only discovered for myself that it wasn't the case when I was > > >>trying to figure out why a custom-compiled version of Wine that I had > > >>made and installed in my TemplateVM wasn't showing up in my AppVM; its > > >>default prefix is /usr/local, which is why). Is there a way to turn off > > >>persistent /usr/local? Or is it something that's baked-in? > > > > BTW, /usr/local == /rw/usrlocal. Its a symlink. > > > > And it's set in the template - so if you don't want it open the template, > remove the symlink and move /usr/local.orig to /usr/local. > Then qubes based on that template wont have persistent /usr/local. > > NB this will break torVMs and maybe other features of your Qubes. > An alternative approach would be to run tripwire against persistent > directories and monitor changes. > > unman Or just compartmentalize more and don't care so much if some of your vms get compromised. Assume some of them will and wipe them when in doubt. But being conscious of the potential issue is a good thing. Tiangha brings up a good point and why to me its silly for some people to care about vms being sudoless. I stopped using dispvms for important tasks. I only use them for random or dangerous tasks now. And its because of that and other things I don't trust them for important tasks anymore. I guess only monitoring a couple directories with tripwire on a few important vms would be ok. But on baremetal linux it used to drive me crazy and can be noisy and I would always miss something. Some extra Automatic hardening is always welcome and would be nice. But I'm sure Qubes devs are busy on other things. -- 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/d07b6daf-b7bf-4c3d-80b1-d7d8bd2acf32%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Scanner use in VM
On Monday, April 10, 2017 at 9:22:47 PM UTC-4, Daniel Acevedo wrote: > I only see my scanner in dom0, using this command: > > # lsusb | grep Canon > > Bus 001 Device 005: ID 04a9:1909 Canon, Inc. CanoScan LiDE 110 > > Of course it doesn't appear in the VMs. > > I know I should assign the USB device where the scanner is plugged to > the VM where I'm going to use it. The problem is that I don't know > which USB Hub I should select (I have 3 different ones) and I'm afraid > of making the wrong move and losing mouse and keyboard control in > Qubes, forcing me to reinstall everything from scratch. > > Any tips would be appreciated. > > Thaks in advance, > Daniel https://www.qubes-os.org/doc/assigning-devices/ scroll down to "finding the right usb controller" -- 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/b535d15f-9e2e-497b-ac5a-c7e004976a5e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Skype Package Installation Issue
On Monday, April 10, 2017 at 11:45:01 PM UTC-4, Nick Geary wrote: > I've installed the Skype .dpm package and installed it using dnf install > ./..dpm. The installation completed without errors. > > However, I don't see skype listed in the AppVm's list of available shortcuts > or within the installed software app. > > I've also tried installing Skype on a Debian template with the same result. > > How do I go about launching the Skype application post install? > > The Skype web application has no option available for Web calls. The section > is greyed out, despite the webcam being loaded on the AppVm and accessable by > Cheese. > > Any help is appreciated. It's been an interesting process. This being the > last step for a functional OS. > > Thanks!! have you tried qvm-sync-appmenus command from terminal? Also to make sure its installed try launching program from the appvm terminal. -- 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/974e90c6-6afb-4e46-9a38-7985e80d3ad1%40googlegroups.com. 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
On Monday, April 10, 2017 at 5:06:30 PM UTC-4, qubenix wrote: > qubenix: > > Andrew David Wong: > >> 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 > >> > >> > > > > Nice. I was just thinking about this after spending some time on my > > routers interface. Thanks for the post! > > > > After testing this, 'sys-net' still shows up on my router interface. > > -- > qubenix > GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 if you are talking about always connecting to your own router I would do a static connection, my router won't know hostname unless I use DHCP. Not sure if this is the case for most routers or not. But its good not to use dhcp for other reasons too. If you hop around public lans then this would be more of a hassle. When I first started using qubes I too didn't like how it showed sys-net as hostname cause it would be obvious you are using Qubes. Changing name is ideal, a script to randomize it would be nice too. -- 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/1b18d551-538c-4cf8-9e71-e24784562191%40googlegroups.com. 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
On Monday, April 10, 2017 at 5:06:30 PM UTC-4, qubenix wrote: > qubenix: > > Andrew David Wong: > >> 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 > >> > >> > > > > Nice. I was just thinking about this after spending some time on my > > routers interface. Thanks for the post! > > > > After testing this, 'sys-net' still shows up on my router interface. > > -- > qubenix > GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 Did the same test and got the same result. Anyone has a solution? I can always change my hostname for something else, but I would prefer not sending the hostname or finding a way to randomize it!!! Dominique -- 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/ec2607a9-c361-4043-b219-76e349f4a790%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Android-x86 on Qubes
On 04/11/2017 12:17 PM, Desobediente wrote: I've tried every possibility to install or boot from live iso both cyanogen mod x86 and android-x86 and I've never had any luck. The HVM just sits there forever with "ANDROID" spinning. It goes on for days. Android 4.4 x86 work and install without any problems on HVM. Where do you have problem? Only 3 problems related to Android that I do not know how to solve: 1) How to emulate Fake Wifi connection (Android must think that he is connected to wifi network. 2) One installer messenger does not work. Say that "not connected". I think it request income/outcome open UDP port. Is it possible to somehow open them on VPN connection before android? 3) How to easy copy files from HVM without Qubes Copy I tried to attach Usb stick to Android, but it does not see it (or does not mount it automatically and I do not know how to mount usb stick) -- 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/c309d056-9ed8-14c6-9c6a-d42fc49a5953%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Android-x86 on Qubes
I've tried every possibility to install or boot from live iso both cyanogen mod x86 and android-x86 and I've never had any luck. The HVM just sits there forever with "ANDROID" spinning. It goes on for days. -- 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/b250d018-2977-4cb7-b77e-ac4f70b7f00e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: off topic - invite codes to 'riseup'
Looking for one as well, getting an activist group started in my area and need some privacy. If someone could PM me one would be greatly appreciated. -- 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/6a97d8af-910e-40ee-9d11-17eb4acd3dc8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
