Auto-attachment based on signed GPTs

[DemiMarie]

How to file a helpful issue

The problem you're addressing (if any)

Auto-attachment of block device partitions is brittle, even in the easy case where the disk (but not necessarily the image on it) is trusted. GUIDs have enough entropy that they are impractical to forge, but they are generally not considered sensitive and so are likely to leak to logs, bug reports, and other places.

The solution you'd like

Support auto-attaching based on signed GUID Partition Tables (GPTs). The signature will be placed in the unused space after the partition table but before the first partition. The signature might also include various information about the device itself.

The value to a user, and who that user might be

Users will be able to establish trust in a block device in a slightly robust way.

Completion criteria checklist

(This section is for developer use only. Please do not modify it.)

[HW42]

Could you expand a bit on the intended use case and the desired security properties that you have in mind?

[rapenne-s]

Could you expand a bit on the intended use case and the desired security properties that you have in mind?

I understand it as an UX improvement. You will be able to make a list of partitions and on which qubes it should attach it when available, instead of connecting the drive and use sys-usb to dispatch it to the right qube. There is even a little security benefit as it will avoid mistake, and also prevent the drive to be used if its partition changed.

[DemiMarie]

Could you expand a bit on the intended use case and the desired security properties that you have in mind?

I understand it as an UX improvement. You will be able to make a list of partitions and on which qubes it should attach it when available, instead of connecting the drive and use sys-usb to dispatch it to the right qube. There is even a little security benefit as it will avoid mistake, and also prevent the drive to be used if its partition changed.

Indeed so! The assumption is that the drive itself is trusted and the whole disk is not accessible by untrusted code, but there might be other disks that are (in their entirity) attached to other qubes or come from other systems.

[marmarek]

What is the practical difference of this approach from using simply disk GUID (also part of GPT)? GPT doesn't say much about partition content (or their trustworthiness for that matter), and signature of GPT isn't really attached to this particular disk or its content - it can be freely copied as long as its copied together with the GPT. So, it remains secure only as long as its secret. Just disk GUID is already 128bits, also unlikely to be guessed, and similarly vulnerable to copying.
You say it can be leaked via logs etc but TBH I don't buy this argument. It's filesystem / partition UUID that often are used in various places, disk GUID not so much.
On the other hand, adding a signature adds a bunch of issues related to key management (where would it be stored? how it would interact with disposable sys-usb? what about backup/restore? what about USB disks you want to trust in several systems? etc).
And also, modifying the disk to add some extra identifier is problematic. It won't work with write-protected USB stick (and those are actually quite useful for things written on a trusted system that are later read on other possibly less trusted systems). And in some cases it may actually break the thing - for example Qubes OS installer would complain, because it verifies checksum of the whole installation image.

[marmarek]

Or if you really don't want to use disk GUID, maybe you can use a hash of the GPT? That would break of somebody changes GPT of course, but I guess it's a rare event.
One other property for using disk GUID is you can easily get it with existing tools (possibly also from outside qubes), which means you can prepare relevant policy also before connecting the device. With hash (or signature) not really, you need a qubes-specific tool for that.

[HW42]

I understand it as an UX improvement. You will be able to make a list of partitions and on which qubes it should attach it when available, instead of connecting the drive and use sys-usb to dispatch it to the right qube. There is even a little security benefit as it will avoid mistake, and also prevent the drive to be used if its partition changed.

I understand why auto-attachment would be desirable. But what I'm wondering is in which specific scenario a signed partition table helps.

Indeed so! The assumption is that the drive itself is trusted and the whole disk is not accessible by untrusted code, but there might be other disks that are (in their entirity) attached to other qubes or come from other systems.

"whole disk is not accessible by untrusted code", so this includes not connecting that disk to another less trusted system, right?

In that case why do you need to sign anything? If you don't like to use the GPT disk ID, since it's (normally) not considered secret, just write another random ID to it, no need to sign anything.

On the other hand if the disk is also connected to less trusted systems, the signed GPT would no longer help with identifying the disk, since it can be copied including it's signature.

[DemiMarie]

I understand it as an UX improvement. You will be able to make a list of partitions and on which qubes it should attach it when available, instead of connecting the drive and use sys-usb to dispatch it to the right qube. There is even a little security benefit as it will avoid mistake, and also prevent the drive to be used if its partition changed.

I understand why auto-attachment would be desirable. But what I'm wondering is in which specific scenario a signed partition table helps.

Preventing impersonation, without relying on data that is likely to be logged by standard tools remaining confidential.

Indeed so! The assumption is that the drive itself is trusted and the whole disk is not accessible by untrusted code, but there might be other disks that are (in their entirity) attached to other qubes or come from other systems.

"whole disk is not accessible by untrusted code", so this includes not connecting that disk to another less trusted system, right?

The idea is that one might have some disks that are connected to untrusted systems (presumably with signed firmware) and others that are not. This would be for disks in the latter category.

[HW42]

Preventing impersonation, without relying on data that is likely to be logged by standard tools remaining confidential.
[...]
The idea is that one might have some disks that are connected to untrusted systems (presumably with signed firmware) and others that are not. This would be for disks in the latter category.

But how helps signing the partition table here? Why not just add another random ID (that has enough entropy and is not logged by standard tools)?

(Where exactly you would store that ID depends on the intended tradeoff, some options: MBR boot sector, behind GPT but before first partition, dedicated (very small) partition, ...)

[DemiMarie]

Preventing impersonation, without relying on data that is likely to be logged by standard tools remaining confidential.
[...]
The idea is that one might have some disks that are connected to untrusted systems (presumably with signed firmware) and others that are not. This would be for disks in the latter category.

But how helps signing the partition table here? Why not just add another random ID (that has enough entropy and is not logged by standard tools)?

(Where exactly you would store that ID depends on the intended tradeoff, some options: MBR boot sector, behind GPT but before first partition, dedicated (very small) partition, ...)

A random ID with enough entropy would work just fine, as long as it doesn’t get logged or used in e.g. qrexec policies without first being hashed.