Re: [qubes-users] Incredible HD thrashing on 4.0
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 -- 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/ddf8ceb6-1758-3ca6-7f6d-3658de12460a%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Best Laptop for Qubes 4+ and Heads
On 08/10/2018 08:25 PM, Franz wrote: On Fri, Aug 10, 2018 at 5:23 PM, Jonathan Brown mailto:jonbrownmaste...@gmail.com>> wrote: How bad does the RAM issue affect your VM number you want to run vs what you can run? Can it handle all the required VMs needed by default along with both Whonix templates and split GPG? yes, a part from the system VMs, I usually run 6 VMs. When the machine is fresh started I can easily reach 9 VMs. But after a couple of days working it doesn't let me start new VMs. How does it actually run performance wise? Smooth and fast. But I never tried gaming or specially intensive tasks. The ivy bridge CPUs are pretty fast.. the last generation before Intel cut max wattage in half with haswell. BTW there are little tricks to improving RAM usage, as my regular system has 8GB. Net and proxy VMs can usually be set to max 350MB RAM, and I find dom0+KDE works smoothly with max RAM at 1500MB. Most personal and work VMs do fine with max RAM at 1500 - 2000MB. -- 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/99d14434-bde6-8d93-f68c-d03e4b2d022b%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes 4.0 sluggish feel
On Fri, Aug 10, 2018 at 6:54 PM wrote: > > On Friday, August 10, 2018 at 12:49:05 AM UTC-4, Outback Dingo wrote: > > On Fri, Aug 10, 2018 at 6:18 AM John S.Recdep wrote: > > > I blame intel speedstep for everything in your local uefi , and dingos :) > > > > great but how do we resolve it... its makes Qubes itself really unuseable > > Maybe try this? > In dom0: > sudo xenpm set-scaling-governor performance Okay thanks for this, it does seem to have helped a bit, at least changing apps and tabs is smoother, though i still get a little bit of video issues > > Brendan > > -- > You received this message because you are subscribed to a topic in the Google > Groups "qubes-users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/qubes-users/SXkX2yQc0ug/unsubscribe. > To unsubscribe from this group and all its topics, 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/ddc0a1d9-7b57-4735-8930-4dd065317790%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/CAKYr3zznZBVB-MuQPLqHL%3DOmCVNq41RxiyEE2-4mt3S1tsHpLg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: X1 Carbon again; Qubes DSDT override?
I have followed these steps with a degree of success. >From a fresh Qubes install, I have compiled the patched kernel and specified >the following kernel command options in my /boot/efi/EFI/qubes/xen.cfg file: acpi_force_s3=5 mem_sleep_default=deep The system now responds to the power button being pushed or the lid being opened in a sleep state. The pulsing power button light turns to a steady light. So that's nice. Unfortunately, the system freezes within seconds. Sometimes at the X lock screen. Sometimes it just remains blank. (Given that this is a UEFI install using the Lenovo Red Hat LiveCD usb disk creation trick, I do not know how to otherwise specify kernel command options at boot. Should I get a menu similar to the GRUB menu I see on a legacy install? Because I don't. I see a row of penguins and then the typical scrolling wall of linux boot text) Any thoughts? -- 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/2ea17c71-0bcf-4dd3-95da-102037d7ee6d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Best Laptop for Qubes 4+ and Heads
On Fri, Aug 10, 2018 at 5:23 PM, Jonathan Brown wrote: > How bad does the RAM issue affect your VM number you want to run vs what > you can run? Can it handle all the required VMs needed by default along > with both Whonix templates and split GPG? > yes, a part from the system VMs, I usually run 6 VMs. When the machine is fresh started I can easily reach 9 VMs. But after a couple of days working it doesn't let me start new VMs. > How does it actually run performance wise? > > Smooth and fast. But I never tried gaming or specially intensive tasks. Please do not top post and do not drop the qubes-users group -- 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-qCd5t%3DF%2Bj35Z82VtPa8CvZWQ9-vo7z1mh0f4af3Vf19fA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes 4.0 sluggish feel
On Friday, August 10, 2018 at 12:49:05 AM UTC-4, Outback Dingo wrote: > On Fri, Aug 10, 2018 at 6:18 AM John S.Recdep wrote: > > I blame intel speedstep for everything in your local uefi , and dingos :) > > great but how do we resolve it... its makes Qubes itself really unuseable Maybe try this? In dom0: sudo xenpm set-scaling-governor performance Brendan -- 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/ddc0a1d9-7b57-4735-8930-4dd065317790%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Minimal builder.conf and template security
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. -- 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/2b7e41d57f49e7beb3e0f3e370272b54.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Xenstore flakiness
On Qubes 4.0, I get intermittent bugs when using qvm-prefs. One example: [user@dom0 ~]$ qvm-prefs sys-whonix netvm sys-firewall [user@dom0 ~]$ qvm-prefs sys-whonix netvm "" usage: qvm-prefs [-h] [--verbose] [--quiet] [--help-properties] [--get] [--set] [--default] VMNAME [PROPERTY] [VALUE] qvm-prefs: error: no such property: 'netvm' [user@dom0 ~]$ qvm-prefs sys-whonix netvm sys-firewall usage: qvm-prefs [-h] [--verbose] [--quiet] [--help-properties] [--get] [--set] [--default] VMNAME [PROPERTY] [VALUE] qvm-prefs: error: no such property: 'netvm' [user@dom0 ~]$ Rebooting fixed it. Another example: [user@dom0 ~]$ qvm-prefs sys-firewall netvm "" xenstored started taking 100% CPU in dom0, and qubes that connect to sys-firewall couldn't start: [user@dom0 ~]$ qvm-create testvm --label red [user@dom0 ~]$ qvm-prefs testvm netvm sys-firewall [user@dom0 ~]$ qvm-start testvm Start failed: internal error: libxenlight failed to create new domain 'testvm', see /var/log/libvirt/libxl/libxl-driver.log for details Relevant log entries: 2018-04-18 01:40:58.186+: libxl: libxl_device.c:1081:device_backend_callback: unable to add device with path /local/domain/5/backend/vif/7/0 2018-04-18 01:40:58.186+: libxl: libxl_create.c:1512:domcreate_attach_devices: unable to add nic devices 2018-04-18 01:41:08.290+: libxl: libxl_device.c:1081:device_backend_callback: unable to remove device with path /local/domain/5/backend/vif/7/0 2018-04-18 01:41:08.304+: libxl: libxl.c:1669:devices_destroy_cb: libxl__devices_destroy failed for 7 To fix this, I had to kill sys-firewall (couldn't shut it down), and restart 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/VKB7RNkg3RwUO1WRmQQXivZcMz2WAFkmvSdSSMi1KLX%40local. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Extreme CPU usage by dom0 on Qubes 4.0
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. -- 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/NshbHkD1xG6ok8YHLZieyWeM680Ct9C3A1bH5FRT3dz%40local. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Incredible HD thrashing on 4.0
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. -- 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/mnKAP70pGMcPXfgVn5L09B0qrQmLBjq1609lLW8POGT%40local. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Minimal builder.conf and template security
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? -- 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/LJ_8bo8--3-1%40tutamail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Spontaneous rebooting
Am I the only one having a problem with Qubes spontaneously rebooting on Intel hardware? Only other reports I see are about AMD problems, but I'm using an Intel Core i3. Happens every few weeks. Sometimes just 1 or 2 weeks, sometimes 5 or 6. Got it on Qubes 3.2, and now 4.0 too (new installation, not upgrade), multiple times. Unlikely to be a hardware problem. The system passed both memtest86 and a multi-day mersenne prime stress test. And other OSes tested on this hardware before I switched to Qubes, including Debian and Windows, never had a problem. The rebooting seems completely random. No apparent trigger, and no warning. Acts like an instant hard reset. Sometimes even when the system is idle, and I haven't touched the console for hours. It's wearingly inevitable enough that I don't even bother intentionally rebooting after system updates anymore, in order to minimize how many reboots I have to deal with (setting my workspace back up is an ordeal), because I know the system will end up spontaneously rebooting a week or two later anyway. -- 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/7r15foDK4EKtC8dX4QBmMKrXGWAaC1OpjAxSSEwGaFQ%40local. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: yubikey password
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. -- 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/150e4742-af7f-4b9c-84b6-4a52faf600e9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes 4.0 sluggish feel
On 08/09/2018 06:48 PM, Outback Dingo wrote: > On Fri, Aug 10, 2018 at 6:18 AM John S.Recdep > wrote: >> >> On 08/06/2018 01:50 PM, Outback Dingo wrote: >>> I dont remeber qubes being so sluggish on a skylake laptop with 64Gb, >>> qubes is installed on a SSD, however it now seems to take an awful >>> long time to switch windows, change tabs in firefox and chhrome, >>> launch VMs >>> >>> also note that screen rendering, i can actually watch web pages paint, >>> as though video is being quirly or something, it is an NVIDIA card >>> >>> any suggestions, nothing is swapping, memory seems ok, ive even >>> allocated 8192 mb to 2 vms which i see it in, both fedora and debian, >>> and i am up to date update wise. >>> >> >> I blame intel speedstep for everything in your local uefi , and dingos :) > > great but how do we resolve it... its makes Qubes itself really unuseable > i guess You would disable it and reboot but ymmv -- 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/aa659861-b0d4-538b-1996-d0b419ade031%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Best Laptop for Qubes 4+ and Heads
On Fri, Aug 10, 2018 at 11:00 AM, wrote: > Heyo, > > I am looking for the best laptop for Qubes 4.0+ to take advantage of all > the features along with Heads. I know Heads only officially supports Lenovo > Thinkpad 230 but is that the best choice to future proof myself and take > advantage of all security benefits? > > How is the 230 on the binary blob front and other firmware? Is there any > other technology besides Heads that could enhance Qubes or provide > better/additional protection? > > Here is more info on Heads http://osresearch.net/ > > Any help is greatly appreciated. > > I own a couple of x230. Yes they support coreboot and Qubes runs pretty well. Also intel ME can be blocked. The problems may be that max RAM is 16MB and CPU has only two cores. The first one is harder to accept for me because I want to keep open more VMs than my RAM allows. But if you can accept these limitations then x230 is pretty good. There are also new motherboards on sale here: https://www.ebay.com/itm/LENOVO-THINKPAD-X230-TABLET-SYSTEM-BOARD-04X3744-I7-3520-WITH-CPU-FAN/322898398982?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649 > -- > 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/98cebf55-53a2-4e24-9e35-575e9d023106%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/CAPzH-qA4pqqkkCMSuEsxv4epN87FZWnXfcA1qDnKvm7fLYwRBQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: yubikey password
On Fri, Aug 10, 2018 at 07:39:45AM -0700, joevio...@gmail.com wrote: > 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. -- 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/20180810153105.lkoo4vi6a3bduqtk%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: yubikey password
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. -- 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/7615fd30-64e4-4594-bd7c-be4b58ecd5c2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: yubikey password
On Fri, Aug 10, 2018 at 02:39:21AM -0700, joevio...@gmail.com wrote: > On Wednesday, 8 August 2018 13:34:14 UTC-4, Arnulf Maria Bultmann wrote: > > Hello, > > I use my yubikey besides other things as a password safe. under windows > > there is no problem to use the yubikey to type in the password into keepass. > > Now I want to use the yubikey for thesame procedure under qubes 4.0. > > I use a security-vm for keepass and connect the yubikey from sys-usb to > > security-vm. It's no problem to use the personalization gui. but how can I > > use the yubikey in this vm as a kind of usb-keyboard to put the stored > > password into keepass or for example an editor? > > thanks in advance for your help > > Arnulf > > I don't think USB keyboards attach to AppVMs normally. They attach to dom0, > and use the qubes-gui windows manager to type and control mouse movement and > clicks. > So if you were to attach it to an AppVM.. I am not sure it could even type > into the session you are viewing. Keyboards and mice have to attach to dom0 > in order for it to interact with the windows it renders. > This isn't quite right. If you have a sys-usb set up, then the keyboard will be attached there, and not to dom0. Have a look at : https://www.qubes-os.org/doc/usb I suspect op needs to edit the RPC policy rules in /etc/qubes-rpc/policy/qubes.InputKeyboard > > Have you considered using Chal/Resp instead of static password? It is way > more secure since you are not using one password for everything... and the > secret never gets send across USB. Keepass works with Challenge / Response, > and even works with LUKS encryption of Qubes OS. KeeChallenge and OtpKeyProv > plugin for Keepass running on mono in a debian AppVM. Then you can attach > the Yubikey to that vm, and Challenge Response with something you know.. > opens the vault. > http://richardbenjaminrush.com/keechallenge/ > -- 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/20180810141751.r3n3pfjvo3i2m2yt%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Best Laptop for Qubes 4+ and Heads
Heyo, I am looking for the best laptop for Qubes 4.0+ to take advantage of all the features along with Heads. I know Heads only officially supports Lenovo Thinkpad 230 but is that the best choice to future proof myself and take advantage of all security benefits? How is the 230 on the binary blob front and other firmware? Is there any other technology besides Heads that could enhance Qubes or provide better/additional protection? Here is more info on Heads http://osresearch.net/ Any help is 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/98cebf55-53a2-4e24-9e35-575e9d023106%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: yubikey password
On Wednesday, 8 August 2018 13:34:14 UTC-4, Arnulf Maria Bultmann wrote: > Hello, > I use my yubikey besides other things as a password safe. under windows there > is no problem to use the yubikey to type in the password into keepass. > Now I want to use the yubikey for thesame procedure under qubes 4.0. > I use a security-vm for keepass and connect the yubikey from sys-usb to > security-vm. It's no problem to use the personalization gui. but how can I > use the yubikey in this vm as a kind of usb-keyboard to put the stored > password into keepass or for example an editor? > thanks in advance for your help > Arnulf I don't think USB keyboards attach to AppVMs normally. They attach to dom0, and use the qubes-gui windows manager to type and control mouse movement and clicks. So if you were to attach it to an AppVM.. I am not sure it could even type into the session you are viewing. Keyboards and mice have to attach to dom0 in order for it to interact with the windows it renders. Have you considered using Chal/Resp instead of static password? It is way more secure since you are not using one password for everything... and the secret never gets send across USB. Keepass works with Challenge / Response, and even works with LUKS encryption of Qubes OS. KeeChallenge and OtpKeyProv plugin for Keepass running on mono in a debian AppVM. Then you can attach the Yubikey to that vm, and Challenge Response with something you know.. opens the vault. http://richardbenjaminrush.com/keechallenge/ -- 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/225ee7fe-639a-4099-b307-ff4a2718d73a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
