Default UsbVM setup by installer

[marmarek]

Reported by joanna on 8 Feb 2013 18:45 UTC
The goal is that a default Qubes installation has no USB controllers assigned to Dom0. This would prevent lots of USB attacks, as discussed in this article:

http://theinvisiblethings.blogspot.com/2011/06/usb-security-challenges.html
Two requirements:

1. PVUSB should work (#531)
2. Keyboard/Mouse should not use USB (typically they don't on most laptops)

Migrated-From: https://wiki.qubes-os.org/ticket/704

[marmarek]

Modified by joanna on 1 Aug 2013 11:57 UTC

[marmarek]

Modified by joanna on 1 Aug 2013 11:57 UTC

[marmarek]

Comment by joanna on 22 Nov 2014 14:28 UTC
While at it, also make sure to block CDROM modules in Dom0 (cdrom, sr_mod, perhaps other?)

CDROM devices are typically SATA, and so they are served by the same PCI device as the main (only) HDD, so they cannot be assigned to a (untrusted) VM. However, it seems to me, like the primary danger from a CDROM/DVDROM is by introduction of large amounts of untrusted input to kernel subsystems (parsing all these metadata when CD is inserted), so we can effectively disable this attack vector by disabling kernel processing of CDROMs, which I believe is what unloading of the said modules do (at least on my system this seems to work that way).

A more questionable is the case of some laptops having swappable CD/DVD devices -- there is some bus exposed there, and it's unclear what an attacker might get by being able to tinker with such a socket. I'm very inclined to believe, however, they cannot do direct DMA that way. That would be really stupid.

In other words, unloading of CDROM handling modules should be just enough :)

[marmarek]

Comment by joanna on 22 Nov 2014 14:28 UTC
While at it, also make sure to block CDROM modules in Dom0 (cdrom, sr_mod, perhaps other?)

CDROM devices are typically SATA, and so they are served by the same PCI device as the main (only) HDD, so they cannot be assigned to a (untrusted) VM. However, it seems to me, like the primary danger from a CDROM/DVDROM is by introduction of large amounts of untrusted input to kernel subsystems (parsing all these metadata when CD is inserted), so we can effectively disable this attack vector by disabling kernel processing of CDROMs, which I believe is what unloading of the said modules do (at least on my system this seems to work that way).

A more questionable is the case of some laptops having swappable CD/DVD devices -- there is some bus exposed there, and it's unclear what an attacker might get by being able to tinker with such a socket. I'm very inclined to believe, however, they cannot do direct DMA that way. That would be really stupid.

In other words, unloading of CDROM handling modules should be just enough :)

[v6ak]

I am in favor of making it optional, although the installer might ask the user. Rationale: Assume you install Qubes on a computer without a PS/2 keyboard.

An advanced solution for such case might be chosing a particular trusted USB controller connected to dom0 (e.g. for keyboard) and connecting the others to usbvm. But this should be IMO just possible, not necessarily easy for wide range of users.

[v6ak]

I am in favor of making it optional, although the installer might ask the user. Rationale: Assume you install Qubes on a computer without a PS/2 keyboard.

An advanced solution for such case might be chosing a particular trusted USB controller connected to dom0 (e.g. for keyboard) and connecting the others to usbvm. But this should be IMO just possible, not necessarily easy for wide range of users.