Re: [qubes-users] Re: epoxy on ram to prevent cold boot attacks?

2016-09-01 Thread johnyjukya 
>> https://freedesktop.org/wiki/Software/PulseAudio/FAQ/#index15h3
>
> I've looked at it few years ago and it was outdated/unmaintained at that
> time already. I gave up on setting this on Win 7. I bet now it's even
> harder.

Yes, weird how neglected it is.  Do people not write utility software for
Windows now?  Is it too locked down by MS (expensive signing) or too
insecure for anyone to bother coding?

Remote sound seems like the type of thing a lot of power users would want,
even on Windows.

>> When I assign a single USB drive to a VM, is dom0 still really in charge
>> of the USB bus, and just shuffling stuff back and forth to the VM(s)?
>
> If you assign a single USB device to VM (using qvm-usb or qvm-block),
> then yes - all the nasty USB stuff is still handled in dom0/sys-usb.
> Only assigning the whole USB controller (PCI device) to a VM will move
> USB processing out of dom0.

So other than the potential of bugs in the stack, and faking a
keyboard/mouse, there's really nothing a USB device could do to provoke
any action (break-in attempts) in dom0?

Would a USB Wifi dongle auto-configure as a second adapter on Qubes?  (I
might check that myself later.)

Mass storage devices will be noted by dom0, but nothing silly like autorun
could happen (unless you set it up manually).  Device impersonation is a
threat, I suppose.  Can one USB device effectively "bus master" to probe a
disk or something like that?

Any other device type that could be a threat via USB?

As long as you have a solid stack and reject HID/network, USB might not be
quite as scary as I thought.

Once you get your keyboard/mouse off of USB.  That recipe for rejecting
HID in one of those links worked great,
/etc/udev/rules.d/99-disable-usb-input.rules:

ACTION=="add", SUBSYSTEM=="input", SUBSYSTEMS=="usb",
ATTRS{authorized}=="1", \
   ENV{PARID}="$id", RUN+="/bin/sh -c 'echo 0
>/proc/bus/usb/devices/$env{PARID}/authorized'"

Any new attempts to insert HID devices are ignored.

I suppose there's a window at boot time before udev configures where a
rogue USB device could impersonate a HID device and try to hijack the
system (e.g. right at grub).  But supervising any boots for any oddness is
trivial (and a good idea).

>> https://dkopecek.github.io/usbguard/blog/2015/USBGuard-vs-UDev
>
> Very interesting project indeed. And it is packaged in Fedora!

N!!!  Lol, I spent hours trying to get that to build.  I had
checked for packages under debian-8, found none, so figured Fedora was
even less likely to have it (being more conservative).

I was even building it under a bare-bones Fedora-23 VM.  I could have just
dnf'd it.

That's a great thing, presumably having undergone review from the Fedora
folks to be in the main repositories.  (If Qubes can't in turn trust
Fedora and its repo, it's toast from the start.)  But I assume you still
don't increase the amount of running dom0 software lightly.

Installing it only brought in libqb (102k) and itself (206k), so it's
fairly lightweight.  Might see how well it agrees with dom0.  :P

> But as you've noted below, if all we need can be done using udev rules,
> it's better to not introduce another complexity.

With Fedora's review (and a fairly small package), I feel a lot more
comfortable with it, perhaps as an option.  Making it easier for people to
track/configure USB devices is a pretty compelling selling point. 
Possibly outweighs the risk of the minimal additional of dom0 software.

> The whole idea of having separate USB VM is to not care about USB
> related compromise. It isn't fully possible with all kind of devices (like
> USB camera - compromised USB VM will be able to sniff the traffic), but
> it is surely an improvement.

Leaving any camera or microphone connected at all isn't for the highly
security conscious.  :)

> It would make sense to have Disposable USB VM - I hope we'll manage to
> have it in Qubes 4.0.

That's interesting.  So, for example, you could possibly configure it such
that if a certain device is inserted, a disposable VM could pop up,
attached to that USB device, that could then run an app (such as keepass).
 When you're done, the DVM goes away.  That's rather tidy.  And safer.

I assume memory freed from a dead VM is wiped upon freeing by Xen?  Or at
least wiped before allocating it elsewhere?

>> Some discussions online argue that USB white-listing isn't helpful,
>> since
>> a BADUSB could just emulate your actual keyboard.  Well, it would have
>> to
>> know the device ID's first.
>
> Yes. But then, such device would be able to communicate with
> only one driver - of that keyboard. Not arbitrary chosen one of hundreds
> of them -> large reduction of attack surface.

I suppose even a brute-force search of device ID's through the relatively
few vendors is feasible (without some protection).

> Of course, if it hit unlocked system (or locked, but know the password),
> controlling keyboard means controlling the whole system. But you can
> guard against such attacks

[qubes-users] Re: QubesOS under VMware - I know I know ...

2016-09-01 Thread Drew White 
On Friday, 2 September 2016 00:31:15 UTC+10, p.@.com  wrote:
> Hi all,
> 
> I am thinking of installing Qubesos on my laptop but before that I would like 
> to play with it before installation. The only option I know is to install it 
> under Vmware. I know this solution is not supported but for educational and 
> learning purposes it would be good to be able to do that.
> Does anybody know if this is possible ? I tried to install it under Vmware 
> but it failed. Any workarounds ? I can even lower the security of QubesOS (if 
> this is somehow possible) to achieve it - this is just for educational 
> purposes.
> Any help ?
> 
> Best regards
> Przemek

If you want to put Qubes under VMWare, I recommend 3.0, it installs every time.

If you have a server, then install Qubes under ESXi, it's what I did, and I've 
not had issues doing it many times before I then put it onto my actual PC.
Qubes 2 also installs easily under VMWare, even on Player or Workstation on 
local PC. Just be sure you have enough Virtual HDD space for it. (32 GB+)

As for 3.2 I'm not sure, I just put it on my Laptop using an HDD I had lying 
around.

So that is 1 way you can accomplish this too.
 - Get another HDD that you have lying around.
 - Install onto that on your PC.
 - Mount HDD under VMWARE.
 - Clone HDD to virtual disk.

 - Boot and start the VM with only the virtual disk.

This method has to sometimes be used, as I was told when I had issues at one 
point on my particular hardware (My laptop).

I did that, and it worked fine under VMWare Player 6.

On ESXi I installed directly on ESXi 5.5, worked first time.

So there are many options to get it working under VMWare.

-- 
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/0f483128-a90f-4876-8910-804dc63bf0d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: epoxy on ram to prevent cold boot attacks?

2016-09-01 Thread Marek Marczykowski-Górecki 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, Sep 01, 2016 at 06:55:05AM -, johnyju...@sigaint.org wrote:
> > On Wed, Aug 31, 2016 at 10:05:59PM -, johnyju...@sigaint.org wrote:
> >> I'm curious to some mentions-in-passing about Andrew's hate for USB
> >> keyboards.  USB-anything isn't good for security, but what in particular
> >> so much worse about USB?  Both USB and PS/2 can keylog, or play
> >> predefined
> >> scripts to try and exploit the system.  One of the dangers of rogue USB
> >> devices is that they can suddenly pretend to be a keyboard (which Linux
> >> will accept without confirmation, something I'm not thrilled about).
> >
> > It is mostly not about the keyboard itself, but other devices on the
> > same bus. Anything that can control the bus to which keyboard is
> > connected, can control the keyboard / pretend to be a keyboard.
> 
> I can understand pretending to be the keyboard, but seeing the keyboard's
> traffic, controlling the keyboard is really possible from another device
> on the bus?  If so, what a fatal flaw in the design of USB.

On, it's about compromising system to which such USB device is
connected.

> > In addition, USB is quite complex and as with all complex code there are
> > bugs.
> 
> I hear you.  I've bit-banged PS/2 protocols myself, and it's not that
> hard.  VUSB has achieved the same with USB, but its a *huge* project (and
> can barely achieve HID use).
> 
> > If you (or someone else) plug a malicious USB device that will exploit
> > some bug in one of million USB device drivers, it can do whatever it
> > want with the other USB devices on the same bus. And if that USB
> > controller live in dom0, it's game over even without injecting malicious
> > keystrokes.
> 
> Yikes.  USB really needs to get out of dom0 all together, just as
> networking has.  I'd also like to see the sound card in its own VM.  With
> Pulse's networkability, it shouldn't be that hard.  One could use the
> Pulse network ability instead of virtualization of the sound card.

Actually our VM audio solution is based on something like this: passing
raw samples (similar to pacat + module-simple-protocol-unix) over vchan
link - socket-like inter-VM connection. See here:
https://github.com/QubesOS/qubes-issues/issues/1590

> That might also be the best route to getting sound working in Windows
> HVM's, although some work is needed on Windows Pulse clients:
> 
> https://freedesktop.org/wiki/Software/PulseAudio/FAQ/#index15h3

I've looked at it few years ago and it was outdated/unmaintained at that
time already. I gave up on setting this on Win 7. I bet now it's even harder.

> When I assign a single USB drive to a VM, is dom0 still really in charge
> of the USB bus, and just shuffling stuff back and forth to the VM(s)?

If you assign a single USB device to VM (using qvm-usb or qvm-block),
then yes - all the nasty USB stuff is still handled in dom0/sys-usb.
Only assigning the whole USB controller (PCI device) to a VM will move
USB processing out of dom0.

> > PS/2 is much better, because you can't connect anything else than input
> > devices there, and attack surface is much smaller.
> 
> Agreed.  It's all I use for mouse/keyboard.
> 
> > Some mitigation would be to use separate USB controller for USB
> > keyboard/mouse and have it in dedicated VM (separate form all-purposes
> > sys-usb).
> 
> Another possibility is some built-in Qubes support for building udev rules
> (similar to how the firewall makes iptables rules), or perhaps adding
> USBGuard to dom0 (or any USB Qube).  A good comparison of the two options
> is here:
> 
> https://dkopecek.github.io/usbguard/blog/2015/USBGuard-vs-UDev

Very interesting project indeed. And it is packaged in Fedora!
But as you've noted below, if all we need can be done using udev rules,
it's better to not introduce another complexity.

> Seems like a great idea for Qubes in mitigating USB dangers, since in
> practice it is so hard to avoid USB all together.  And that problem is
> only getting worse.
> 
> One dodgy USB device from the dollar store, and your pwned.  Or an
> NSA/syndicate-implanted commercial hard drive with alternate identities
> lurking.

The whole idea of having separate USB VM is to not care about USB
related compromise. It isn't fully possible with all kind of devices (like
USB camera - compromised USB VM will be able to sniff the traffic), but
it is surely an improvement.
It would make sense to have Disposable USB VM - I hope we'll manage to
have it in Qubes 4.0.

> Some discussions online argue that USB white-listing isn't helpful, since
> a BADUSB could just emulate your actual keyboard.  Well, it would have to
> know the device ID's first.

Yes. But then, such device would be able to communicate with
only one driver - of that keyboard. Not arbitrary chosen one of hundreds
of them -> large reduction of attack surface.
Of course, if it hit unlocked system (or locked, but know the password),
controlling keyboard means controlling

Re: [qubes-users] QubesOS under VMware - I know I know ...

2016-09-01 Thread Andrew David Wong 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-09-01 07:31, p.@.com wrote:
> Hi all,
> 
> I am thinking of installing Qubesos on my laptop but before that I 
> would like to play with it before installation. The only option I 
> know is to install it under Vmware. I know this solution is not 
> supported but for educational and learning purposes it would be
> good to be able to do that. Does anybody know if this is possible ?
> I tried to install it under Vmware but it failed. Any workarounds ?
> I can even lower the security of QubesOS (if this is somehow
> possible) to achieve it - this is just for educational purposes.
> Any help ?
> 
> Best regards Przemek
> 

Note that Qubes can be installed to a portable USB drive. It will run
more slowly from such a device, but it can make testing more
accessible, since it doesn't disturb your existing OS.

At least one user has reported success with booting Qubes under
VMware, but others have not been able to replicate these results:

https://github.com/QubesOS/qubes-issues/issues/2249

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJXyHFsAAoJENtN07w5UDAwFLoQAJ4Xajn/HiOWEpNvYi9awl9e
5tFJmTptC45E5T7OV4sh1gnlZc1M8Ctmg2MQ5Z2XwSQDzxa3IXW/ZJHvpK/oiyKu
ME4zjsBJU+Kpi27q4/SfwZN16/KnbnHObM/rhRvX9W8K8B0aGAQD8s8hW0kkeiQV
6wFGpgujBsl+Jie/XcQX9r2cfAt7H5I8TnT9ZLGnmU4WJY+I3O6+WLXGvF0UyLQy
TJfp9h0kYy3IhwvtGWxanEQ8geN6wPUZUchtcUNJ1TZ9/qZjEkGV31VXTMp8d+a3
b/cLGF8k/0FV4rkoHfa5odbIQIrwf4bkdN6LWEfy6kSxcYl6OCHWHZLWGzubqoTd
AHL0b0EBeCti/BHXCWUMhnLIC0zue6LLxXhzZrdHB0b+lAlTZ62Na9oq4uC7APGf
oMCIiWMLqsiuyouS2dxdKTK7PY1CKnyVw+G+SlU/l7y9bKLRR8p0HzsDp1EJquni
S7pxuvQLlR4MlpRY18B8KwOBAwfbYtJOW87DxPl5GfMDwvV7fXiRNUXQJerXJFsG
uaSMNXfj//TkU8Ryb+7tXbSiIwl/Q3qjUSvdJgciSBlwlfcG1eVKJCoQP4ae++W0
wbVFR7aBrfZ/tr/7BG8ZEyp4poW6FE8xxc6RIedLH2D55kZpNG8lwl37ykPhSEyS
+WgZr8WoHHBbdCr3jJc7
=IhAj
-END PGP SIGNATURE-

-- 
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/9fe390c4-5f37-7156-4dc0-ecfa07970099%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] ASUS ZenBook 3 + Qubes OS

2016-09-01 Thread Darko Vuković 

https://www.asus.com/Notebooks/ASUS-ZenBook-3-UX390UA/


;)

-- 
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/b2bee74a-4baa-4271-91f9-270a1ad00924%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] ASUS ZenBook 3 + Qubes

2016-09-01 Thread Darko Vuković 
;)

-- 
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/ad1b784e-4af6-4027-83c3-4e0694749969%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: QubesOS under VMware - I know I know ...

2016-09-01 Thread Darko Vuković 
On Thursday, September 1, 2016 at 4:31:15 PM UTC+2, p.@.com wrote:
> Hi all,
> 
> I am thinking of installing Qubesos on my laptop but before that I would like 
> to play with it before installation. The only option I know is to install it 
> under Vmware. I know this solution is not supported but for educational and 
> learning purposes it would be good to be able to do that.
> Does anybody know if this is possible ? I tried to install it under Vmware 
> but it failed. Any workarounds ? I can even lower the security of QubesOS (if 
> this is somehow possible) to achieve it - this is just for educational 
> purposes.
> Any help ?
> 
> Best regards
> Przemek

I have managed to do this once but I wasn't able to repeat it for some reason...

-- 
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/faa0207e-a285-4dc2-b1bc-86e82ce1b626%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Display Calibration and Audio Equalizer for Dom0 ?

2016-09-01 Thread kalle 
how can I calibrate my display in qubes ?
my display is quite yellow

what good program should I install into qubes, dom0 to calibrate it ?


is there any good audio equalizer like dell waves maxx audio & windows sound 
settings, that modifies
the sound output ?

like virtual surround, noise cancellation, bass/trebble modifier...

-- 
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/08c3ca4d-1ede-4759-91e9-61c3d2546a2d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] QubesOS under VMware - I know I know ...

2016-09-01 Thread p.@.com 
Hi all,

I am thinking of installing Qubesos on my laptop but before that I would like 
to play with it before installation. The only option I know is to install it 
under Vmware. I know this solution is not supported but for educational and 
learning purposes it would be good to be able to do that.
Does anybody know if this is possible ? I tried to install it under Vmware but 
it failed. Any workarounds ? I can even lower the security of QubesOS (if this 
is somehow possible) to achieve it - this is just for educational purposes.
Any help ?

Best regards
Przemek

-- 
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/b5c87957-1599-46c0-8273-60e14b896f96%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: OSError: [Errno 2] while reinstalling a TemplateVM

2016-09-01 Thread telepherickrick 
This as just been solved by creating this folder in dom0 :

mkdir /var/lib/qubes/vm-templates/dummy/apps.templates

Then I was able to get a menu in Qubes VM Manager to switch from "dummy" to 
"debian-8" template.

All is working fine now.

-- 
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/98607c33-b847-48a1-8824-73eb486d7b23%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] R3.2 rc2 blank screen - screenlock issue?

2016-09-01 Thread richard . f . gould 
Happened again overnight - kill -HUP xsettingsd got it useable again.

-- 
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/e471416e-84b1-420f-8b84-15ff6fc5c48c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] installing Signal on Qubes mini-HOWTO

2016-09-01 Thread IX4 Svs 
On Thu, Sep 1, 2016 at 2:21 AM, Andrew David Wong  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 2016-08-31 15:50, IX4 Svs wrote:
> > On Wed, Aug 24, 2016 at 11:10 PM, Andrew David Wong 
> > wrote:
> >
> >>
> >> On 2016-08-15 14:43, IX4 Svs wrote:
> >>> On Mon, Aug 15, 2016 at 10:19 AM, Andrew David Wong 
> >>> wrote:
> >>>
> 
>  On 2016-08-14 15:22, IX4 Svs wrote:
> > Just spent a few minutes to figure this out so I thought I'd
> > share.
> >
> 
>  Thanks, Alex! Would you mind if we added this to the docs at some
>  point?
> 
> 
> >>> Not at all - especially if you improve my clumsy way of creating the
> >> custom
> >>> shortcut (steps 7-12) and use the proper Qubes way that Nicklaus
> >>> linked to.
> >>>
> >>> Cheers,
> >>>
> >>> Alex
> >>>
> >>
> >> Added:
> >>
> >> https://www.qubes-os.org/doc/signal/
> >>
> >>
> > Andrew, thanks for adding this to the documentation.
> >
> > I'm afraid my DIY shortcut kludge does not survive some(potentially boot
> > time) script and is wiped away from the taskbar, only to be replaced by a
> > default "Chrome browser" shortcut. I admit I don't quite comprehend what
> > the actual implementation of
> > https://www.qubes-os.org/doc/managing-appvm-shortcuts/#tocAnchor-1-1-1
> > should be.
>
> Neither do I. I've always make my custom shortcuts the same general way
> you do.
>
>
Ah, we have a usability issue here then.


> > A worked example that replaces all but the first step of the " Creating a
> > Shortcut in KDE" section of https://www.qubes-os.org/doc/signal/ would
> be
> > very much welcome.
> >
>
> Agreed.
>

Can someone who has figured out how to create one-click buttons to launch
arbitrary applications in AppVMs chime in with an example please? I'll then
test it and Andrew can stick it in the wiki for all Qubes users to benefit.

Thanks,

Alex

-- 
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/CAEe-%3DTecrTrJ20i73xC2nQFqcnGY17fPNuNR1Xs0A%3Dern2FeoA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: epoxy on ram to prevent cold boot attacks?

2016-09-01 Thread johnyjukya 
> This is scary:
>
> https://hakshop.myshopify.com/collections/usb-rubber-ducky/products/usb-rubber-ducky-deluxe?variant=353378649

Related, and (disturbingly) informative:

https://github.com/brandonlw/Psychson

JJ

-- 
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/c2872d8b7c663d10b867f7b43b735ad3.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: epoxy on ram to prevent cold boot attacks?

2016-09-01 Thread johnyjukya 
> On Wed, Aug 31, 2016 at 10:05:59PM -, johnyju...@sigaint.org wrote:
>> I'm curious to some mentions-in-passing about Andrew's hate for USB
>> keyboards.  USB-anything isn't good for security, but what in particular
>> so much worse about USB?  Both USB and PS/2 can keylog, or play
>> predefined
>> scripts to try and exploit the system.  One of the dangers of rogue USB
>> devices is that they can suddenly pretend to be a keyboard (which Linux
>> will accept without confirmation, something I'm not thrilled about).
>
> It is mostly not about the keyboard itself, but other devices on the
> same bus. Anything that can control the bus to which keyboard is
> connected, can control the keyboard / pretend to be a keyboard.

I can understand pretending to be the keyboard, but seeing the keyboard's
traffic, controlling the keyboard is really possible from another device
on the bus?  If so, what a fatal flaw in the design of USB.

> In addition, USB is quite complex and as with all complex code there are
> bugs.

I hear you.  I've bit-banged PS/2 protocols myself, and it's not that
hard.  VUSB has achieved the same with USB, but its a *huge* project (and
can barely achieve HID use).

> If you (or someone else) plug a malicious USB device that will exploit
> some bug in one of million USB device drivers, it can do whatever it
> want with the other USB devices on the same bus. And if that USB
> controller live in dom0, it's game over even without injecting malicious
> keystrokes.

Yikes.  USB really needs to get out of dom0 all together, just as
networking has.  I'd also like to see the sound card in its own VM.  With
Pulse's networkability, it shouldn't be that hard.  One could use the
Pulse network ability instead of virtualization of the sound card.

That might also be the best route to getting sound working in Windows
HVM's, although some work is needed on Windows Pulse clients:

https://freedesktop.org/wiki/Software/PulseAudio/FAQ/#index15h3

When I assign a single USB drive to a VM, is dom0 still really in charge
of the USB bus, and just shuffling stuff back and forth to the VM(s)?

> PS/2 is much better, because you can't connect anything else than input
> devices there, and attack surface is much smaller.

Agreed.  It's all I use for mouse/keyboard.

> Some mitigation would be to use separate USB controller for USB
> keyboard/mouse and have it in dedicated VM (separate form all-purposes
> sys-usb).

Another possibility is some built-in Qubes support for building udev rules
(similar to how the firewall makes iptables rules), or perhaps adding
USBGuard to dom0 (or any USB Qube).  A good comparison of the two options
is here:

https://dkopecek.github.io/usbguard/blog/2015/USBGuard-vs-UDev

Seems like a great idea for Qubes in mitigating USB dangers, since in
practice it is so hard to avoid USB all together.  And that problem is
only getting worse.

One dodgy USB device from the dollar store, and your pwned.  Or an
NSA/syndicate-implanted commercial hard drive with alternate identities
lurking.

I'm always tempted, but ultimately avoid, unusually low-priced USB
devices, lol.

I've been passed USB keys from some rather suspect individuals in the
past; I've quarantined them, and should (carefully, on a non-critical
system) take a more detailed peek someday, lol.

Some discussions online argue that USB white-listing isn't helpful, since
a BADUSB could just emulate your actual keyboard.  Well, it would have to
know the device ID's first.

Even if it gloms my keyboard's USB vendor/device ID's and tires to imitate
it, the system could spot the fact that there's a second similar device
but on another USB port, no?  Or is USB so stupid that the system couldn't
differentiate the two (or the fact that there is two)?

While the USBGuard project looks admirable, I'm guessing the more
attractive option would be for Qubes to add support for creating custom
udev whitelists, as the less software in dom0, the better.

Although USBGuard isn't a huge project (the tarball is <1M) and if you're
going to otherwise have to write the code yourself, it might be better to
just audit USBGuard and include it in some form.  If someone else has
already put in much of the required thought and effort . . .

Even a pop-up notification when a new HID device is added could be useful.
 The fact that keyboard/mice are silently accepted is a bit scary.  I
might add some scripts to watch dmesg for such events, and more actively
warn me.

All just food for thought.

I'll be adding udev whitelist rules to dom0 very shortly.

Another idea I saw was restricting HID devices to *one* keyboard and *one*
mouse, so if a BADUSB comes along trying to be another keyboard, it
doesn't work.  Or even better, alarm bells go off.

I was thinking earlier that some form of a "USB Firewall" hardware device
might be cool to create; one that goes into each USB port in between each
device and the PC, and only passes a specific device, or only a HID device
(and doesn't