Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disallow persistent attachment of block devices #447

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

DemiMarie
Copy link
Contributor

It is very fragile.

Marking as draft because this is not yet tested.

@SaswatPadhi
Copy link

It would be great if we could attach block devices based on UUID. Is that not exposed by Xen?

Or are there other issues as well with persistently attaching block devices?

@DemiMarie
Copy link
Contributor Author

It would be great if we could attach block devices based on UUID. Is that not exposed by Xen?

The problem with UUIDs is that they are dependent solely on the contents of the block device. This is a security problem, because a qube could overwrite a device’s UUID with the UUID of a different device, and cause it to be assigned to a different qube.

Partition UUIDs would be somewhat better, since (IIRC) they are stored in the partition table, which (if you are exporting a partition) is not under the control of the frontend. However, they are still controlled by the block device, and so are still spoofable by it.

For physical (as opposed to virtual) devices, the safest approach that I am aware of is to designate devices based on their paths in /sys/devices. Those are ugly and not human-memorable, but they are determined by the hardware topology and so are unspoofable. They do, however, depend on devices being plugged in to the same place each time.

@SaswatPadhi
Copy link

Many thanks for explaining this.

They do, however, depend on devices being plugged in to the same place each time.

This might be a reasonable tradeoff between security and the convenience of persistent attachments. If I plug in my device to a different slot then I won't see it auto attach and I'd just unplug and plug it in again to the whitelisted slot.

@marmarek
Copy link
Member

marmarek commented Apr 3, 2022

Those are ugly and not human-memorable, but they are determined by the hardware topology and so are unspoofable

But they aren't necessary stable. Plus, that would for example depend on to which USB port you connect a device, which may be undesirable.

Maybe /dev/disk/by-id/ ?

@DemiMarie
Copy link
Contributor Author

Those are ugly and not human-memorable, but they are determined by the hardware topology and so are unspoofable

But they aren't necessary stable. Plus, that would for example depend on to which USB port you connect a device, which may be undesirable.

I believe almost any non-cryptographic solution will either be spoofable or have this problem. The only possible exceptions are partition UUIDs and other such identifiers, which can be spoofed by someone with access to the underlying device, but not by someone with only access to the partition.

Maybe /dev/disk/by-id/ ?

I believe that works for virtual devices, but it is probably spoofable for physical devices.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants