Thoughts on non-block device USB compartmentalization

[Eric Kmetz]

Hey folks,

Newer Qubes user here with some thoughts on USB.

Pardon me if I'm making some nave assumptions about the integrity of Qubes' current handling of I2C/non-block device drivers, but I was wondering how the idea would resonate and (hopefully) be vetted amongst those of you with a high degree of Qubes USB knowledge.

Once upon a time, before virtual private servers and other common cloud-type solutions were mainstream, I did some solaris kernel module programming around the concept virtualizing hosted web customers' syscall ACLs.  This was to restrict or permit a granularity of what types of BSD socket API calls a customer could make (who could listen for incoming TCP/UDP, what ports etc).

In any case, this might be a philosophical separation from what Qubes is about, but as Qubes users we do have the ability to configure our setups such that were short circuiting some of the built-in protections, right?  I could more or less make dom0 network-accessible from any other HVM/System/Proxy/AppVM right?  Probably even run a DMZ server off of it with the right sys-net config...

So I'm playing around with a few types of radio devices, software defined radio, 802.15.4 WPAN stuff, etc.   And I notice (like almost many I2C USB devices) that the driver takes over and affirms recognition/init within the dmesg or other such system output.  In my case lately there's a UART virtual com port to FTDI phase and then whatever PHY WPAN device driver loads up and takes on more functionality.

So I'm thinking about USB device access and risks involved, and wondering if there might not be some way to modulate/granulate the USB port itself.

Could we either/or:

Encapsulate USB IO in such a way that a bad device could by mitigated?  Perhaps 'modulating' in in a Qubes USBVM driver of sorts (modulate, if you will), until it may be demodulated or otherwise handed off the the HVM/AppVM?   Perhaps we bring the USB device online appearing to be an entire USB bus, and from that our demodulated, explicitly allowed device is let in.

I've seen a few convos on USB/IP, usbVM / PV-USB. I just thought I would add another to the mix.    I could still be completely lost on why the I2C VM Bus memory handling is still a problem.   

Best,

Eric Kmetz

[Robert Fisk]

Hi Eric,

There are two issues in play here:

1 The need to isolate USB devices for security purposes.
2 The usability problem of limited USB host controllers locking devices
to a single VM.

Both problems can be solved with sufficient host controllers, but this
is not a practical reality, especially with laptops. ITL has implemented
a super-handy software passthrough layer for block devices, but as you
know this is not useful for the myriad of other device types we use.

So then the question becomes: how do we provide software passthrough for
other device types? If we use a super secure sanitised protocol for each
different device type as done for block devices, this is a crap-ton of
development work and currently impractical.

We could also use generic software passthrough as done by various
USB-over-IP things. This provides the widest compatibility, but also
opens a gaping hole between VMs which goes against the Qubes philosophy.
I can't speak for ITL but neither option looks good to me!

This issue has been of interest to me for some time, and I am currently
prototyping a hardware gadget that provides security-through-isolation
at the hardware level. Due to be presented at Kiwicon in a couple of
weeks :)

https://github.com/robertfisk/usg

Regards,
Robert

[Konstantin Ryabitsev]

On Sun, Nov 29, 2015 at 12:12:00PM +1300, Robert Fisk wrote:
> So then the question becomes: how do we provide software passthrough for
> other device types? If we use a super secure sanitised protocol for each
> different device type as done for block devices, this is a crap-ton of
> development work and currently impractical.

Does it make sense to prioritize security devices like smartcards?
Currently, there is no way to use a smartcard with Qubes without
assigning the USB bus with the reader to the AppVM.

(I'm just throwing this out there without any knowledge of how hard it
would be to implement. :))

Best,
Konstantin

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

In case of GnuPG(-enabled cards), you can (probably) use split gpg for
that - simply have backend in USB VM and configure gpg there to use
smartcard.

But it probably won't work for generic x509 certs handling. Unless
someone made pkcs11 module which uses gpg as a backend (which could be
replaced by split gpg then).

Anyway, given a lot of security problems with USB, it's better to use
split gpg with offline VM as a backend, instead of gpg with smartcard.
Think of it: while it's (probably) true that your private key wouldn't
be stolen when stored on smartcard, your USB VM has ultimate control
over its usage. PIN protection gives you nothing, because it can be
easily sniffed.

- --
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWWw8cAAoJENuP0xzK19cs8CEIAIjVKPiaQRDVrTFLLw8kSCUh
Lv/7gohXPxEcJmeEe/3AM17e7/MaKtmkDhPf9QPFWvFQxpyzEYIouXB8leEQC8tA
V/899zbHjniwJ5fJgnTL+HASmO1qjNmOgwiutQbPLd4tId3C44YnPwvShabuApT8
ZJ2RVyjBclE23hNKP4SrwV5VlrMgWMarPusE8XxOaTK3sV+1KpOjwu16O830mfSe
3hrrai8VW5vKphT2hygLS4q/mNMpUjRoKHdWmZL3PoBTTB1QRJI1xB34waP/Oz1j
f2ACHb9KwWyT9C559YX9VrVPZK5+wl3YHww4UOdxJJqFsfEA+AiotXnhn/0NI4I=
=yJWh
-----END PGP SIGNATURE-----

[Konstantin Ryabitsev]

On Sun, Nov 29, 2015 at 03:43:40PM +0100, Marek Marczykowski-Górecki wrote:
> In case of GnuPG(-enabled cards), you can (probably) use split gpg for
> that - simply have backend in USB VM and configure gpg there to use
> smartcard.

Does qubes gpg agent support using GnuPG's Auth key for ssh? It wasn't
obvious from reading about split-gpg.

> But it probably won't work for generic x509 certs handling. Unless
> someone made pkcs11 module which uses gpg as a backend (which could be
> replaced by split gpg then).
>
> Anyway, given a lot of security problems with USB, it's better to use
> split gpg with offline VM as a backend, instead of gpg with smartcard.
> Think of it: while it's (probably) true that your private key wouldn't
> be stolen when stored on smartcard, your USB VM has ultimate control
> over its usage. PIN protection gives you nothing, because it can be
> easily sniffed.

I would have agreed with you until recently, but the latest crop of
yubikeys supports "require touch for operation" functionality. Even if
the yubikey is connected to my port and you know the PIN, you can't use
it unless I also touch the button within 30 seconds of the request. I
believe this is similar to the advantages you get with split-gpg
regarding protecting encrypted data vs. just the private keys.

-K

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sun, Nov 29, 2015 at 10:03:47AM -0500, Konstantin Ryabitsev wrote:
> On Sun, Nov 29, 2015 at 03:43:40PM +0100, Marek Marczykowski-Górecki wrote:
> > In case of GnuPG(-enabled cards), you can (probably) use split gpg for
> > that - simply have backend in USB VM and configure gpg there to use
> > smartcard.
>
> Does qubes gpg agent support using GnuPG's Auth key for ssh? It wasn't
> obvious from reading about split-gpg.

It's just a wrapper around gpg, with some whitelist for options. If that
works with just normal gpg, it should also work with split-gpg. But if
that's about gpg agent (not main gpg itself), it probably wont. In that
case, take a look at split-gpg2 - which does the same at gpg agent
protocol level:
https://github.com/QubesOS/qubes-issues/issues/474#issuecomment-156885755

> > But it probably won't work for generic x509 certs handling. Unless
> > someone made pkcs11 module which uses gpg as a backend (which could be
> > replaced by split gpg then).
> >
> > Anyway, given a lot of security problems with USB, it's better to use
> > split gpg with offline VM as a backend, instead of gpg with smartcard.
> > Think of it: while it's (probably) true that your private key wouldn't
> > be stolen when stored on smartcard, your USB VM has ultimate control
> > over its usage. PIN protection gives you nothing, because it can be
> > easily sniffed.
>
> I would have agreed with you until recently, but the latest crop of
> yubikeys supports "require touch for operation" functionality. Even if
> the yubikey is connected to my port and you know the PIN, you can't use
> it unless I also touch the button within 30 seconds of the request. I
> believe this is similar to the advantages you get with split-gpg
> regarding protecting encrypted data vs. just the private keys.

Indeed this somehow improves the situation. You still don't know what
you are signing, but this problem isn't solved by split gpg either (it
isn't implemented, but in theory it is possible to have some preview of
what you're are really going to sign). Similar about decryption - it may
be possible to decrypt the data and view it in some isolated DispVM,
instead of passing back to the source VM.

- --
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWWxhoAAoJENuP0xzK19csoy4H/3osFlgz6n92pc8gTu/EjVbm
mBEKM/9p5qyR04RvriiiPM1onB7jRfCXQmTETprdsZaKezqJO4ABcPXqy4UU7Xar
PtOQOTDIQpPbl7QiRp59gjbkdDuRb77HfyacZuj+BRL1SOqg9a7z7MWSQ8dMc59t
dQPYsYyqycsNf3P4Q6HmVEAnriNzQMJ5EjnbUH9hsqlGHtT6Fbkz788cHvdKI8Cr
I1CaPSmUDhgte/tKNvERS0IrQx/7Du+bqXvwxjoZ/Dy8+4+D1oGva+dCgvDyZp7C
G1bfUhq6BitwRqZPZC7HNAo+zzfoew3QU/jNyy9orcoIFW5Jky07GQEpg0Dg4rI=
=tqTk
-----END PGP SIGNATURE-----