Find a way to enable VeraCrypt support by default

[intrigeri]

Hi!

in the review process of the new VeraCrypt support @segfault has added (#495) on behalf of Tails, concerns were raised about the potentially problematic performance impact of testing all devices for "does it look like random data", which this code uses as a way to try and identify VeraCrypt volumes.

For the record & the curious, this discussion started at #495 (comment)

Back then, the simplest way we've found to unblock the review and merge process was to add a flag file: the entire VeraCrypt code path is enabled if, and only if, /etc/udisks2/tcrypt.conf exists. And by default it does not exist. This was a great first step.

Building on top of this, VeraCrypt support is being pushed higher in the stack: GNOME Disks 3.30 supports this, we got plenty of code merged already in GLib and GTK+, and segfault submitted merge requests for user-friendly integration with the rest of GNOME so that any GNOME user can unlock VeraCrypt volumes. And at this point, the need to create /etc/udisks2/tcrypt.conf as root obviously becomes a serious UX problem.

The idea behind the /etc/udisks2/tcrypt.conf flag file was that it would be shipped by an extra package, so enabling VeraCrypt support would boil down to installing that package, which feels acceptable from a UX point of view. But in practice, this is going to be a pain (at best) or simply won't work at all: first, one would need to create and maintain such a package for all major distros, which seems to be lots of busywork; second, some distros such as Debian frown upon a package that ships only one file (let alone an empty one).

So at this point, I'd like us to go back to the drawing board and find a way to enable VeraCrypt support by default in udisks.

First, a question: @vojtechtrefny, who raised the performance impact concerns initially, wrote "Maybe I'm just too paranoid or scared of breaking something". Indeed, we never checked whether there was an actual performance problem with enabling the VeraCrypt code path by default. What kind of data would we need to assess whether there's an actual problem? I'm happy to get some measurements once I'm told what data you folks would like to see :) I assume we need benchmarks with real-world hardware.

Second, if the previous topic does not reach the "actually we can enable this code path by default" conclusion, my proposal would be to enable this code path in more cases than just "iff. the flag file exists" (if (udisks_daemon_get_enable_tcrypt (daemon))). I've spent some time thinking about it and it looks like this could work fine: we could guard that code with these conditions: if the flag file exists (i.e. its meaning becomes "inconditionally do the check on all block devices") OR the block device is on a removable drive (the main use case and a pretty efficient filter) OR (ID_FS_USAGE is empty AND the device has no partition table). Then, for those without the flag file, i.e. most users:

• Performance cost is close to zero in the majority of cases, i.e. no removable drive is plugged and ID_FS_USAGE is non-empty for all devices except drives that have a partition table.
• The "udisks will not be able to unlock a given TCRYPT volume with a chance of n / 65536, where n = number of filesystems with a 2 byte magic number that are supported by udev" problem only exists for non-removable drives, which is a minority case already.

Would this be a reasonable trade-off?

segfault tells me that all of these properties should be easily accessible in udisks_linux_block_update so implementing this looks doable.

[vojtechtrefny]

we could guard that code with these conditions: if the flag file exists (i.e. its meaning becomes "inconditionally do the check on all block devices") OR the block device is on a removable drive (the main use case and a pretty efficient filter) OR (ID_FS_USAGE is empty AND the device has no partition table).

I think I was a little too paranoid. I think we could enable this by default and these conditions look reasonable.
The code looks stable, it's working for our users (GNOME Disks) so I think enabling this in 2.9.0 should be safe.

@tbzatek @vpodzime thoughts?

[tbzatek]

I'm okay with continually refining detection scenarios and always scanning removable media sounds good for now. Plugging removable media in is a user-aware action and if anything goes wrong like I/O errors during reading, user would be aware of what's happening and how to fix it (unplug the broken thing).

Allowing the detection system-wide is always risky and no surprise @vojtechtrefny is scared, I am too. With the continous effort to push udisks in the enterprise segment minimizing the I/O load is a crucial goal. Keep in mind that large systems may have obscure block devices present that are more prone to read errors during automatic discovery (either as the setup is not prepared for such automatic probing or as a result of race condition during devices still being set up). Performance audit of udisks (and its clients on one side, udev on the other side) on such large systems is still planned but no real work has been done yet.

Another idea just crossed my mind - adding menu command on the client side (gnome-disks and nautilus?) trigerring some kind of 'deep probe'. This is probably unrealistic nowadays given the effor to keep GUI clean however it may become actual over time in case new crypto systems that obfuscate their presence are introduced. Of course we should try hard to properly identify filesystems on a first guess until then.

[intrigeri]

Hi! Thank you all for the useful input.

I'm okay with continually refining detection scenarios and always scanning removable media sounds good for now.

I understand that everyone involved in this conversation agrees on the "if the flag file exists (i.e. its meaning becomes "inconditionally do the check on all block devices") OR the block device is on a removable drive (the main use case and a pretty efficient filter)" part. So I'll schedule time to start working on this; this will be volunteer work with a relaxed timeline and I'm very happy if someone else takes it over (C is not on top of my skillset, to say the least).

Keep in mind that large systems may have obscure block devices present that are more prone to read errors during automatic discovery (either as the setup is not prepared for such automatic probing or as a result of race condition during devices still being set up).

I'm not familiar with such systems so this is good to know, thanks. @tbzatek, did you have specific implications in mind that affect my proposal? Was it about the "OR (`ID_FS_USAGE` is empty AND the device has no partition table)" clause? Or is it more of a general reminder to keep in mind?

[fishface60]

GPT GUID 8C8F8EFF-AC95-4770-814A-21994F2DBC8F has been allocated to VeraCrypt, and has been available in GPT fdisk since February 2020.
I can't find out how VeraCrypt is meant to format it itself, but if a partition has that GUID it would be safe to assume it can be opened with VeraCrypt.