search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
543 stars 48 forks source link

Bad disk format #7423

Open ZYousef opened 2 years ago

ZYousef commented 2 years ago

How to file a helpful issue

Qubes OS release

R4.1

Brief summary

Qubes Installer unable to reclaim storage on new installation if you uncheck disk encryption

Steps to reproduce

Uncheck Disk passphrase encryption on Qubes installation, then in new installation reclaim storage space and continue to other configs

Expected behavior

Installer turns on automatic disk partitioning

Actual behavior

Installer fails to reclaim space with error in disk configuration

Note that this behavior only shows if you opt-out of disk encryption.

DemiMarie commented 2 years ago

Not too surprised. No disk encryption is not a configuration any of the developers use, so it gets very little testing.

andrewdavidwong commented 2 years ago

Not too surprised. No disk encryption is not a configuration any of the developers use, so it gets very little testing.

Should it even be an option? It wouldn't be unreasonable for a security-oriented OS to require FDE. The backup tool already requires encryption.

DemiMarie commented 2 years ago

Not too surprised. No disk encryption is not a configuration any of the developers use, so it gets very little testing.

Should it even be an option? It wouldn't be unreasonable for a security-oriented OS to require FDE. The backup tool already requires encryption.

@ninavizz thoughts?

andrewdavidwong commented 2 years ago

You could keep the checkbox but make it checked and grayed out. Hovering the cursor over it would say something like, "Qubes OS requires full-disk encryption to be enabled."

This would communicate several things to the user:

DemiMarie commented 2 years ago

You could keep the checkbox but make it checked and grayed out. Hovering the cursor over it would say something like, "Qubes OS requires full-disk encryption to be enabled."

This would communicate several things to the user:

  • FDE will be applied.
  • It's not optional.
  • It (probably) can't be configured beyond whatever options are presented to you in the installer or advanced documentation.
  • This was all intentional, not just an oversight.

I like this approach, but there is actually a (very niche) caveat: Some filesystems (ZFS, bcachefs) have built-in authenticated encryption support that has significant advantages over that provided by dm-crypt. Since neither of these are supported by the Qubes OS installer, this does not matter in practice.

GWeck commented 2 years ago

On test systems needing no enhanced security, installation without disk encryption makes sense, especially in multi-boot environments where access to the Qubes file structure from another system (e.g. Linux) might be needed for some tests.

I am using such configurations for several years now, without any problems - but well aware that these systems are not suitable for using any critical data.

So I would propose to leave the installer as it is - having disk encryption enabled as default but allowing to switch it off, possibly after showing some warning.

marmarek commented 2 years ago

I was just going to comment about test systems case.

There is also advanced partitioning - if user creates partition layout manually, you forcefully include encryption. If anything, you can check if it's included (which BTW is not a trivial task, depending on the layout) and refuse to continue if it isn't.

But the idea of a warning if one disables encryption for automatic partitioning is a good one.

BTW, this is yet another point to the topic of "what configurations are supported", including some communication to the user about it.

andrewdavidwong commented 2 years ago

I was just going to comment about test systems case.

The same argument for testing can be made about the Qubes backup system, yet we no longer allow unencrypted backups. I wonder whether this is a principled distinction or just a random inconsistency.

BTW, this is yet another point to the topic of "what configurations are supported", including some communication to the user about it.

It sounds like non-FDE configurations shouldn't be supported, even if they continue to be allowed for testing purposes.

marmarek commented 2 years ago

The same argument for testing can be made about the Qubes backup system

Not really. Having no encryption on test system disk makes debugging various issues (not just storage-related) easier. And in some environments - faster. The some does not apply to backups (encrypting backups or not applies to backups only, which is rather isolated functionality).

It sounds like non-FDE configurations shouldn't be supported, even if they continue to be allowed for testing purposes.

Yes. But we are going into area where it is tricky for the user to tell whether their current configuration is supported.

andrewdavidwong commented 2 years ago

The same argument for testing can be made about the Qubes backup system

Not really. Having no encryption on test system disk makes debugging various issues (not just storage-related) easier. And in some environments - faster. The some does not apply to backups (encrypting backups or not applies to backups only, which is rather isolated functionality).

The argument that can be made for both is something like, "You should allow not using encryption when that makes testing easier." Allowing unencrypted backups would make testing the backup system easier, so the same principle can be applied to both, even though allowing unencrypted system drives is more useful in more cases. There may be a difference in the degree or magnitude of the benefit, but not in the underlying principle. Nonetheless, choosing to allow one but not the other on purely practical grounds (more useful in more cases) seems fine.

It sounds like non-FDE configurations shouldn't be supported, even if they continue to be allowed for testing purposes.

Yes. But we are going into area where it is tricky for the user to tell whether their current configuration is supported.

Sure, I just wanted us to decide on our position before attempting to communicate it to users. As for the UX, I can imagine some general approaches:

However, users might not remember whether they disabled FDE when first installing (potentially years prior to being asked), so, ideally, there would also be a user-friendly way to tell whether FDE is present in an existing installation:

GWeck commented 2 years ago

Such a system health tool would be good in any case as a means to check the system integrity, at least to some extent. Maybe the installation method used was faulty or some later modification - of the user or of a possible attacker - violated the system integrity. Such a check could help the user to ensure that no such violation occurred or help the user to pinpoint and possible correct it.

DemiMarie commented 2 years ago

Such a system health tool would be good in any case as a means to check the system integrity, at least to some extent. Maybe the installation method used was faulty or some later modification - of the user or of a possible attacker - violated the system integrity. Such a check could help the user to ensure that no such violation occurred or help the user to pinpoint and possible correct it.

For the “user messed up” case this is fine, but the attacker case can only be handled by a live system.