On Sunday, 12 August 2018 09:59:57 UTC-4, Unman wrote: > On Fri, Aug 10, 2018 at 11:00:30AM -0700, : > > On Friday, 10 August 2018 11:31:08 UTC-4, Unman wrote: > > > On Fri, Aug 10, 2018 at 07:39:45AM -0700, > > > > Both /etc/qubes-rpc/policy/qubes.InputKeyboard and InputMouse, should > > > > say something like this. > > > > > > > > sys-usb dom0 allow,user=root > > > > > > > > Yes, If you have a sys-usb set up, then the USB keyboard will attach > > > > there first. More specifically, the USB Host Controller that the USB > > > > keyboard is plugged into is attached to sys-usb. But the keyboard > > > > device is immediately sent to dom0 per the rpc policy. Because a > > > > keyboard that stays attached to sys-usb, can only type into sys-usb. > > > > And not the interactive window you see when you open up a terminal for > > > > sys-usb... but rather its own session. > > > > dom0 needs the keyboard and mouse. The USB Host Controller still > > > > resides in sys-usb, but the USB raw data passes to dom0 upon boot. > > > > > > > > Unfortunately, the rpc policy is generic based on all USB devices > > > > enumerating as a keyboard. So it may not be able to selectively attach > > > > a yubikey to an AppVM. > > > > > > > > > > But the point is that the yubikey will be attached to a different qube, > > > and can be treated as a keyboard there. This means that one can > > > selectively link the yubikey to distinct qubes for input there, and the > > > sys-usb policy will not be relevant. > > > The Input.Keyboard policy needs to be set for the qube to which the > > > yubikey is attached. > > > > Yeah, that would be nice if it were that granular. > > > > I don't have my yubikey set for a static key, but let me test this with my > > input stick, which is like a USB rubber ducky. It enumerator as a > > keyboard, and I have just attached it to the app VM I am typing on. > > I am speech to text on my phone, Bluetooth to InputStick USB and typing > > into here. > > > > It only works with, "sys-usb dom0 allow,user=root" in > > /etc/qubes-rpc/policy/qubes.InputKeyboard > > And it does NOT work with "sys-usb APPVM_NAME allow,user=root". > > No USB device attaching is needed, as the rpc rule simple allows dom0 > > access to sys-usb keyboard. > > > > As I said... Keyboards need to be sent to dom0, or else it cannot type in > > the GUI. > > > > This will work for all USB keyboards as you cannot specify Yubikey > > keystrokes only type in a single AppVM. Not the most secure... which is > > why Qubes recommends PS2 keyboards if running on a desktop and using the > > built in keyboard on laptops. It avoids the USB blanket rule for keyboards > > going to dom0. And since LUKS encryption passphrases are entered after > > initramfs hides usb from boot process, a non-usb keyboard is essential for > > full disk encryption. > > > > All that said, > > it is still a much more secure option to use ykchalresp which comes with > > yubikey tools. The USB device that does this function is not the keyboard > > part, and you have to explicitly Attach to the VM you want. Also, no > > static key to be sniffed or accidentally typed somewhere. I use it for > > KeePass, LUKS, PAM.d login, OTP tokens, everything. > > > > > > What you say about connecting keyboards isn't quite true. > If you have passed the device through to a qube, then you need to set > the policy *for that qube*. i.e - > <connected qube> dom0 allow, user=root > > I don't use yubikeys so I cant speak for them, but that works for > keyboards. It does mean that the attached keyboard input *could* be sent to > any qube after user error. > > Of course, the granularity of passthrough is currently missing, but it's > possible > to hack this in various ways. > > If you create a HVM and assign it a USB controller, then usb attached > devices can insert key strokes *without* using qubes.InputKeyboard. This > looks like a reasonable approach if you have more than one controller, > and keeps the usb keystrokes confined to the qube. > > If you only have one controller, then you could stop the Sender service > in the qube, let the keyboard do it's stuff in that qube, remove the > yubikey, and then re-enable the service. A bit unwieldy but security > always comes at a price, and you could automate this with a key > combination. > > It's also possible to use qrexec to directly pass keystrokes from one > qube to another. You can manually run the input proxy service and pipe > it through to another qube. I've hacked this via dom0 (poc) and it works > fine - you also need to process the /dev/input/event input to generate > keyboard input in X in the qube, but that's pretty standard. If it's of > interest I could work this up. > > unman
> "If you have passed the device through to a qube, then you need to set the policy *for that qube*. i.e - <connected qube> dom0 allow, user=root " Yes, and I did say that before, "It only works with, "sys-usb dom0 allow,user=root" in /etc/qubes-rpc/policy/qubes.InputKeyboard" The "device" is attached to sys-usb and the "keyboard" must be sent to dom0 to send keystrokes to any vm normally. But, "sys-usb <security-vm for keepass> allow,user=root" does NOT work. > "If you create a HVM and assign it a USB controller, then usb attached devices can insert key strokes *without* using qubes.InputKeyboard." I'm testing this, and it doesn't work. sys-usb is an HVM, it has the USB controller assigned... and qubes.InputKeyboard is NOT allowing to dom0. With a USB Keyboard plugged into this controller, it does not type into an open sys-usb window. I double tested with another HVM appvm with a different USB PCI card attached to it. Nothing. The problem is this: How does an attached keyboard connect to that AppVM's X server? Dom0 does this by default, because it has to be the window manager for all the DomU's. This is proven by my tests in an hvm I created with an iso, without qubes-gui installed. It is running as full desktop (not windowed). I attached the controller, and all keystrokes do show up in this vm. That's because dom0 is not handling the windows in this vm. > "use qrexec to directly pass keystrokes from one qube to another" Yes, that's easy if the source qube was dom0. Any other qube, a usb keyboard won't show up in xinput as a keyboard. X is connected to dom0, and not the actual AppVM that that the USB device is attached to. Yes, you could get a raw usb keyboard stream from /dev/input/ and pass that through qrexec to the destination vm, decode and type it out using xdotool. I've used xdotool to type into an AppVM, from dom0. So it should work if you can convert the /dev/input into ascii. A python module is capable of this. With only 1 USB Host controller, then you may have to run a script as root on sys-usb to send the raw keystrokes through qrexec to the destination. -- 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/853fc45d-fb76-4e5c-9e78-df4596f3464b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
