New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

using sys-usb + usb keyboard + full disk encryption = inactive usb keyboard when you are asked to enter decryption key #2270

Open
0spinboson opened this Issue Aug 26, 2016 · 26 comments

Comments

Projects
None yet
8 participants
@0spinboson
Copy link

0spinboson commented Aug 26, 2016

Qubes OS version (e.g., R3.1):

R3.2rc2


Expected behavior:

I expected to be able to enter the decryption password using my (wireless, so unavoidably) USB keyboard.

Actual behavior:

USB keyboard is inactive; could only enter password using ps/2-connected kb

Steps to reproduce the behavior:

use full disk encryption; use a usb-keyboard, enable sys-usb, allow the keyboard to be passed to dom0 (in the manner described in the faq/documentation). reboot.

General notes:

If for whatever reason it is undesirable / impossible to enable the keyboard, it may be wise to put up a big fat warning that you won't be able to enter your decryption key after reboot. :)

@0spinboson 0spinboson changed the title usb-sys + usb keyboard + full disk encryption = inactive keyboard usb-sys + usb keyboard + full disk encryption = unusable keyboard when you are asked to enter decryption key Aug 26, 2016

@0spinboson 0spinboson changed the title usb-sys + usb keyboard + full disk encryption = unusable keyboard when you are asked to enter decryption key sys-usb icw usb keyboard & full disk encryption = unusable keyboard when you are asked to enter decryption key Aug 26, 2016

@0spinboson 0spinboson changed the title sys-usb icw usb keyboard & full disk encryption = unusable keyboard when you are asked to enter decryption key using sys-usb + usb keyboard + full disk encryption = inactive usb keyboard when you are asked to enter decryption key Aug 26, 2016

@entr0py

This comment has been minimized.

Copy link

entr0py commented Aug 26, 2016

If you are referring to the LUKS password on boot, your keyboard being non-functional is not related to Qubes' USB isolation, since at that point in the boot process, Qubes hasn't had a chance to load at all.

Most likely, your keyboard driver isn't included in Fedora's initramfs. You'll have to add it using dracut - specifics will depend on your model.

@0spinboson

This comment has been minimized.

Copy link

0spinboson commented Aug 26, 2016

Hm, that is quite peculiar, as I am quite certain that I could enter the password just fine until I enabled the USB cube. Oh well, I'll have a look at dracut then. :)

@andrewdavidwong

This comment has been minimized.

Copy link
Member

andrewdavidwong commented Aug 27, 2016

Can you please test it without and without the the USB qube enabled, then report back?

@0spinboson

This comment has been minimized.

Copy link

0spinboson commented Aug 27, 2016

Sure. Can I just delete the usb qube to disable it, or should I do
something else first?

On Sat, Aug 27, 2016 at 4:29 AM, Andrew David Wong <notifications@github.com

wrote:

Can you please test it without and without the the USB qube enabled, then
report back?


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#2270 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AUGeHJzakPtT1ilsqNfdIEo-wK5l_kTHks5qj6DvgaJpZM4JuSpw
.

@andrewdavidwong

This comment has been minimized.

Copy link
Member

andrewdavidwong commented Aug 27, 2016

It's not necessary to delete it. You can temporarily disable it either by not having it auto-start or by unassigning your USB controller(s) from it.

@andrewdavidwong

This comment has been minimized.

Copy link
Member

andrewdavidwong commented Aug 27, 2016

Note, however, that if you created the USB qube by checking the box in the installer, then your USB controller(s) are probably hidden from dom0. To unhide them, reverse the procedure here (under "Hide all USB controllers from dom0"), i.e., remove rd.qubes.hide_all_usb instead of adding it.

@andrewdavidwong

This comment has been minimized.

Copy link
Member

andrewdavidwong commented Aug 27, 2016

Also note, of course, that this means your USB controllers will be attached to dom0, so do this only with USB devices you trust.

@0spinboson

This comment has been minimized.

Copy link

0spinboson commented Aug 27, 2016

I would try, but I don't see that file (probably because I'm using EFI
boot), and I'm not sure where else to look.

(Btw, I didn't create the USB qube during installation, but via the method
described in the documentation, yet usb devices are still hidden from dom0
even with all of the devices removed from the usb qube.)

On Sat, Aug 27, 2016 at 8:46 AM, Andrew David Wong <notifications@github.com

wrote:

Note, however, that if you created the USB qube by checking the box in the
installer, then your USB controller(s) are probably hidden from dom0. To
unhide them, reverse the procedure here
https://www.qubes-os.org/doc/usb/#tocAnchor-1-1-2 (under "Hide all USB
controllers from dom0"), i.e., remove rd.qubes.hide_all_usb instead of
adding it.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#2270 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AUGeHBRYMbXNOD5o1sh36UtchGfbDuiHks5qj91BgaJpZM4JuSpw
.

@andrewdavidwong

This comment has been minimized.

Copy link
Member

andrewdavidwong commented Aug 28, 2016

Note that if a USB controller is delegated to a domU, it will not be automatically returned to dom0 within that session:

https://www.qubes-os.org/doc/assigning-devices/#tocAnchor-1-1-4

@marmarek

This comment has been minimized.

Copy link
Member

marmarek commented Aug 30, 2016

On Sat, Aug 27, 2016 at 02:33:16AM -0700, 0spinboson wrote:

I would try, but I don't see that file (probably because I'm using EFI
boot), and I'm not sure where else to look.

/boot/efi/EFI/qubes/xen.efi

And yes, if you enabled USB qube, it hides all the USB controllers from
dom0, even before it gets started. So, if your only keyboard is on USB,
you need at least to undo this hiding. But then, when sys-usb is started
it will again get USB controllers out of dom0, leaving you without
keyboard.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

@0spinboson

This comment has been minimized.

Copy link

0spinboson commented Aug 30, 2016

Okay, that doesn't sound like I'll be able to work around it, esp. given that I have no clue how to edit the binary file xen.efi :)
Anyway, considering that this behavior is either intended or unavoidable, and not worked around all that easily, I would suggest inserting a warning somewhere, probably on the usb documentation page. (I'd be happy to do this myself, if that would help?)

@0spinboson

This comment has been minimized.

Copy link

0spinboson commented Aug 30, 2016

BTW, for completeness I installed a fresh QubesOs 3.2rc2 on an empty drive I had lying around, again with FDE enabled. Rebooted a few times without sys-usb enabled/installed, so without USB devices being hidden from dom0. USB keyboard worked fine. Then enabled sys-usb, rebooted. Result: USB keyboard could no longer be used to enter the password.

@entr0py

This comment has been minimized.

Copy link

entr0py commented Aug 30, 2016

  1. I stand corrected - my apologies:

    if you enabled USB qube, it hides all the USB controllers from dom0, even before it gets started.

  2. Since 0spinboson created sys-usb manually, rd.qubes.hide_all_usb should not be set. There's no reason why Qubes would block his USB keyboard from functioning at the LUKS password prompt, even if the controller was assigned to a domU. Correct?

I just tested this by rebooting my Qubes with USB keyboard attached to controller assigned to sys-usb. Keyboard worked fine entering LUKS password then ceased functioning once sys-usb was loaded. Plugging back into dom0 USB controller, keyboard worked again.

Rebooted a few times without sys-usb enabled/installed, so without USB devices being hidden from dom0. USB keyboard worked fine. Then enabled sys-usb, rebooted. Result: USB keyboard could no longer be used to enter the password.

Now I'm confused. Has this behavior changed from 3.1 to 3.2?

@0spinboson

This comment has been minimized.

Copy link

0spinboson commented Aug 30, 2016

Note that I created it 'manually' using the same commands that I understand the setup uses, namely by entering "qubesctl top.enable qvm.sys-usb", then "qubesctl state.highstate".

As for the change in behavior: I guess so. :)

@entr0py

This comment has been minimized.

Copy link

entr0py commented Aug 30, 2016

That might account for the difference. I just created a new AppVM and passed the controller to it.

@0spinboson

This comment has been minimized.

Copy link

0spinboson commented Aug 30, 2016

Not to want to seem more paranoid than I do merely by using this OS, but doesn't this/that mean that your USB controllers aren't wholly locked down while your system is booting? :)

@marmarek

This comment has been minimized.

Copy link
Member

marmarek commented Aug 30, 2016

Okay, that doesn't sound like I'll be able to work around it, esp. given that I have no clue how to edit the binary file xen.efi :)

Sorry, I meant xen.cfg.

@andrewdavidwong

This comment has been minimized.

Copy link
Member

andrewdavidwong commented Aug 31, 2016

Not to want to seem more paranoid than I do merely by using this OS, but doesn't this/that mean that your USB controllers aren't wholly locked down while your system is booting? :)

My understanding is that this is correct. This is why @rootkovska recommends physically unplugging all (untrusted) USB devices when rebooting. Qubes isn't around to isolate USB controllers before it starts running.

@entr0py

This comment has been minimized.

Copy link

entr0py commented Aug 31, 2016

Not to want to seem more paranoid than I do merely by using this OS, but doesn't this/that mean that your USB controllers aren't wholly locked down while your system is booting? :)

Yes. My reasoning:

  1. If my system is booting it's because I booted it. If it's booting without my knowledge, I've got far bigger problems than my USB controllers.
  2. I have multiple USB controllers. sys-usb controller is empty before booting/shutdown. Keyboard is connected to a dom0 USB controller. If my keyboard firmware is malicious, it's far too late to save me.

Your point is valid though - especially as it relates to opportunities for user error. If I used my USB ports for anything more than infrequent file transfers, I would probably lock it all down. [Didn't realize that password entry would be disabled though. Thanks for heads up. I guess a laptop without ps/2 would have to boot another os and then edit the /boot partition?]

@Sen-Dion

This comment has been minimized.

Copy link

Sen-Dion commented Oct 11, 2016

Is it possible to lock all USB controllers with an exception of the one in dom0 that handles USB keyboard (and mouse)?

@InnovativeInventor

This comment has been minimized.

Copy link

InnovativeInventor commented Oct 29, 2017

A warning on the page would be nice to have on this part of the page
[here](https://www.qubes-os.org/doc/usb/#Creating and Using a USB qube)

How would I get keyboard access to Qubes again?

Edit: I figured it out (instructions are below for anyone who gets into the same circumstance that I got myself into)

First, I booted into a rescue system using a qubes installation drive.
Next, it required me editing /boot/efi/EFI/qubes/xen.cfg (note, not efi) and getting rid of rd.qubes.hide_all_usb to allow for my encryption password to be entered
Then, I deleted /var/lib/qubes/servicevms/sys-usb to get rid of the usb vm so I can actually use the Qubes operating system.

I hope this helps others.

@InnovativeInventor

This comment has been minimized.

Copy link

InnovativeInventor commented Oct 29, 2017

I just created a pull request to amend the docs to have a nice warning up top. I think this will help prevent others from messing up.

@marmarek

This comment has been minimized.

Copy link
Member

marmarek commented Oct 29, 2017

Next, it required me editing /boot/efi/EFI/qubes/xen.cfg (note, not efi) and getting rid of rd.qubes.hide_all_usb to allow for my encryption password to be entered

This is for EFI. For non-efi, edit /boot/grub2/grub.cfg and /etc/default/grub (the former is generated from the latter, but you may not be able to launch the generator in rescue mode).

Then, I deleted /var/lib/qubes/servicevms/sys-usb to get rid of the usb vm so I can actually use the Qubes operating system.

This is very bad idea. If you want to remove sys-usb, do it properly from running system. You can use USB keyboard with sys-usb, it isn't enabled (and is prevented by installer by default) because it has security implications. See here: https://www.qubes-os.org/doc/usb/#how-to-use-a-usb-keyboard

But if you are in a situation where you have sys-usb and the only keyboard you have is USB (and didn't followed above instruction), you can prevent its autostart by systemctl disable qubes-vm@sys-usb.service, or simply by removing /etc/systemd/system/multi-user.target.wants/qubes-vm@sys-usb.service symlink.

@marmarek

This comment has been minimized.

Copy link
Member

marmarek commented Oct 29, 2017

@andrewdavidwong andrewdavidwong added the ux label Oct 29, 2017

@andrewdavidwong andrewdavidwong added this to the Release 3.2 updates milestone Oct 29, 2017

@andrewdavidwong andrewdavidwong added C: core and removed C: other labels Oct 29, 2017

@andrewdavidwong andrewdavidwong added the bug label Apr 3, 2018

@homotopycolimit

This comment has been minimized.

Copy link

homotopycolimit commented Apr 11, 2018

I find myself in the same situation. I could not enter my LUKS password after creating the USB vm in Qubes 4.0.

I booted into a rescue system and removed the rd.qubes.hide_all_usb from xen.cfg and rebooted.
I know get as far as the login screen where again the keyboard again does not work (even though the mouse does).

How do I get rid of the usb vm from within the rescue system. How can I undo whatever sudo qubesctl state.sls qvm.sys-usb did?

nvm - I found it (above) simply by removing /etc/systemd/system/multi-user.target.wants/qubes-vm@sys-usb.service symlink.

@adubois

This comment has been minimized.

Copy link

adubois commented Dec 8, 2018

I had issues with some liveCD not having the right version of LVM tools and showing me corrupted LV (would not activate and needing malnual fix). Used Fedora (2GB stick required) and it was OK.
$ sudo mount /dev/sda1 /mnt
$ vi /mnt/xen-4.x.x.config
Deleted rd.qubes.hide_all_usb from all the boot options.
$ sudo umount /mnt
$ sudo cryptsetup open /dev/sda2 qubes
$ sudo mount /dev/qubes_dom0/root /mnt
$ sudo rm /etc/systemd/system/multi-user.target.wants/qubes-vm@sys-usb.service
$ sudo umount /mnt

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment