>> 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,

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

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!

Noooooooo!!!  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 with 2FA:
> https://www.qubes-os.org/doc/yubi-key/ (check also "USB keyboard" link
> at the top)

I really like two-factor.  I'm not sure I'd trust any such device I
received via the post, though, lol.  You'd really want to get a device
verified from a trusted source.  Or roll your own.

One-time-passwords are very interesting as well.  The otpw package and a
related PAM package can let you hook in the features.  Gives you printable
numbered lists of passwords to hang onto safely.  The system will prompt
you for one by number, and you also have a prefix password component as
well (so a stolen list doesn't necessarily give up the keys).

Should be relatively easy to hook into dom0 for the screen lock.  More of
an advanced user feature, likely.

> This is indeed interesting project. I think I've seen something similar
> for USB storage (to avoid USB disk pretending being a keyboard). But the
> one designed specifically for HID devices could do one additional
> thing: encrypt+sign all the traffic. Then such encrypted HID traffic
> would be decrypted in dom0, so USB VM would _not_ know the key and even
> when compromised will have very little ability to manipulate real
> keystrokes (or inject additional ones).

I like the idea of

> This will not guard against some timing attacks etc, but still would be
> an improvement.

Are timing attacks much of a problem?  I would think they're fairly rare.?

And few VM's actively doing different things, it's probably even more
challenging and less of a threat than a more monolithic system.


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

Reply via email to