On Sun, Aug 12, 2018 at 08:59:12AM -0700, [email protected] wrote: > 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.
That's a TemplateBasedHVM and InputKeyboard is running, but (as you say) not allowed - I advised creating a HVM (Standalone) and you'll see it works. You refer to this case below. People have reported using yubikeys in this configuration in the past. > > 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 [email protected]. > To post to this group, send email to [email protected]. > 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. -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20180813144058.6fosofg4xv3ixfpy%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
