Opened 2 years ago
Closed 20 months ago
#226 closed enhancement (implemented)
Safe USB block devices/DVD attach to VMs
| Reported by: | marmarek | Owned by: | marmarek |
|---|---|---|---|
| Priority: | major | Milestone: | Release 1 Beta 3 |
| Component: | kernel | Keywords: | |
| Cc: |
Description
For now, xen-4 + linux-2.6.34.xenlinux.qubes doesn't work with PV USB.
xm usb-attach gives OOPS in domU (something about creating duplicate entry in sysfs).
For future investigation, maybe upgrade kernel in domU will solve the problem.
Change History (9)
comment:1 Changed 2 years ago by joanna
- Type changed from defect to enhancement
comment:2 Changed 2 years ago by marmarek
comment:3 Changed 2 years ago by joanna
- Summary changed from PV USB Attach to Safe USB block devices/DVD attach to VMs
We decided to implement USB/DVD attach via xm block-attach. This requires, however, that we modify Dom0 kernel to not parse the block device's partition table (for security reasons).
Changes the name of the ticket accordingly.
comment:4 Changed 23 months ago by joanna
As I wrote in an email some time ago:
After I successfully used my USB disk yesterday via my NetVM, I started
thinking that we simple might not need pvusb at all.
First, there are a few types of USB devices that are most commonly
plugged into the USB ports:
1) USB storage
2) USB modems (e.g. 3G)
3) USB keyboards and mouses
4) USB authentication tokens/smart cards
Regarding #3 and #4 -- for obvious reasons we would like to keep them in
the most trusted domain, the Dom0.
So, we're left only with 3G modems and storage devices. Now, adding to
the fact that a security-conscious user might (should) always use
LUKS/trucrypt/etc to securely store data on an external USB disk, it
should be perfectly acceptable to share one domain that has access to
both 3G modems as well as all the pluggable USB disks. Most likely this
should be a different domain than the default NetVM (which itself has
large attack vector through exposition to untrusted WiFis? in
hotels/airports via their WiFi? drivers and dhcp client-like tools),
because of this threat:
http://www.pcpro.co.uk/news/368383/40gb-of-data-that-costs-the-same-as-a-house
So, the bottom line is that if the user is able to delegate a USB
controller (that servs the USB external ports), then all the user might
need to take full advantage of this setup is that:
1) our UsbVM be also a type of netvm (to take advantage of 3G modems)
2) should use blkbk to expose (untrusted) block devices to other domains
(those can later use cryptsetup or truecrypt to turn them into
ultimately trusted storage).
As a bonus (for those systems where the USB controllers can be nicely
divided into 1) those that serve externa USB ports, and 2) those that
serve only internal USB devices -- like it is on my Core i5 laptop), we
get resistance to all sorts of USB attacks via malicious devices that
turn out to be e.g. malicious keyboards. In order to protect against
malicious partitions one would need to delegate single volumes (e.g.
phy:/dev/sda1) instead of the whole devices (e.g. phy:/dev/sda) -- would
that be all that is needed?
The only problem would be with systems that do not strictly divide USB
controllers into those that serv external USB ports and those that serve
only the internal ones (such as: camera, fingerprint reader, and
(optionally) internal keyboard and mouse). Still, the use of pvusb would
not change much in this case, would it?
So, the bottom line is: all we need in the UsbVM is a blkbk, not a pvusb
back. Which is cool, because this is a well tested code.
Regarding the USB-based auth tokens/smart cards -- one might argue that
they would be unusable in this setup. But there are two counter-arguments:
1) I'm pretty sure pvusb, at least at current stage, would not support
many such tokens anyway,
2) We are preparing a nice alternative for a crypto card
using... qvm-run -- stay tuned!
comment:5 Changed 23 months ago by joanna
- Milestone changed from Release 1 Beta 2 to Release 1 Beta 3
So, I don't think we should do anything more in this areas as of Beta 2. In Beta 3 we might think how to provide a nice, user-friendly UI (e.g. via Qubes Manager) that would hide the details of doing xl attach (so, would also know which domain is providing blkback for a given device).
So, moving this to Beta 3.
comment:6 Changed 20 months ago by joanna
So, the idea is that every domain that has assigned some device, such as a USB controller, which provides a block device, creates a key in xen store, informing Dom0 about it.
Then we will have a tool in Dom0, e.g. qvm-block, that would allow to do things such as:
- qvm-block -l, which would list all available block devices in the system (including their friendly names)
- qvm-block -a <block_dev> <appvm>, which would attach the device (possibly owned by some other domain) to the domain <appvm>
- qvm-block -r <block_dev> <-- which would detach the device.
A special case might be handling of CDROM devices.
comment:7 Changed 20 months ago by marmarek
- Status changed from new to accepted
comment:8 Changed 20 months ago by marmarek
- fix xl tool to not verify device name (fails when backend!=dom0)
- auto detach device when underlaying dev disconnected (eg. stick removed)
comment:9 Changed 20 months ago by marmarek
- Resolution set to implemented
- Status changed from accepted to closed
Kernel message from domU on usb-attach (2.6.34...):