[dm-crypt] LUKS2 resizing

[Andrius Štikonas]

Hi,

I was testing how well KDE Partition Manager works on LUKS2 partitions.
Apparently, it fails to resize them. It seems that now cryptsetup resize asks
for passphrase before resizing the container.

Unfortunately, I wasn't able to find any documentation on this. So, the passphrase
is now required to resize the container? When I tried entering wrong passphrase,
cryptsetup silently returns exit code 2, not 0. I guess cryptsetup refused to resize. Am I right?

Andrius

[Ondrej Kozina]

Post by Andrius Å tikonas
I was testing how well KDE Partition Manager works on LUKS2 partitions.
Apparently, it fails to resize them. It seems that now cryptsetup resize asks
for passphrase before resizing the container.

Yes, cryptsetup utility asks for passphrase if it detects volume key was
previously passed to dm-crypt via kernel keyring service. VK is passed
to kernel keyring by default for LUKS2 devices.

Post by Andrius Å tikonas
Unfortunately, I wasn't able to find any documentation on this. So, the passphrase
is now required to resize the container? When I tried entering wrong passphrase,
cryptsetup silently returns exit code 2, not 0. I guess cryptsetup refused to resize. Am I right?

Unfortunately we forgot to regenerate doxygen API documentation together
with 2.0.0 final release. But we fixed the mistake recently.

See note at bottom of crypt_resize() description:
https://gitlab.com/cryptsetup/cryptsetup/wikis/API/group__crypt-actions.html#ga168bcd5097cdf64774540fdeaacefbc0

On libcryptsetup API level, you can either query active device
(crypt_get_active_device()) and check for CRYPT_ACTIVATE_KEYRING_KEY
flag. The flag raised means you should load volume key to keyring before
crypt_resize(). Or, you can detect return value from crypt_resize. The
-EPERM hints you basically the same.

Thank you for the report. I'll check the silent failure with cryptsetup
utility. Yes, in general exit status != 0 says the operation was not
performed.

Regards
Ondrej

[Andrius Štikonas]

Hi,

I don't think --ask-always option would be necessary... I think cryptsetup status is more than enough.
I have to do some screen scrubbing in other places too, e.g. new file system (and version version) detection
code now screen scrubs "udevadm info --query property" to detect whether e.g. it is LUKS1 or LUKS2 or even FAT12.

Actually, do I even need cryptsetup status KDE Partitition Manager only allows resizing unlocked LUKS volumes
(so that internal file system can also be resized). So if I understand correctly it will never ask for passphrase in LUKS1
case but it will always ask in LUKS2 case.

Andrius

Exit code status should be fine for me. I'll just check for it to be 0. I can't really
use libcryptsetup anyway, I need to use cryptsetup executable as
KDE Partition Manager is a GUI app and linking to libcryptsetup would
require the whole app to be running as root which is a security issue for
GUI apps.

I see.
Well, you may either detect volume key was passed via kernel keyring to
dm-crypt by following command: cryptsetup status <name>
"key location: keyring". If you see such line you know cryptsetup
resize will ask for passphrase. But yes, it's screen scrubbing, not
comfortable.
Or, we may implement option --ask-always (or similar) and cryptsetup
resize will ask always for the passphrase to verify (and also load)
volume key during resize operation.
Would it help?
Also do you mind if I repost this e-mail back to mail list so that
others see my answer?
O.

[Ondrej Kozina]

Post by Andrius Å tikonas
So if I understand correctly it will never ask for passphrase in LUKS1
case but it will always ask in LUKS2 case.

Not always for every LUKS2 device. It will always ask for a passphrase
if the volume key is passed via kernel keyring (hence the cryptsetup
status cmd for detection).

LUKS1 devices doesn't use kernel keyring for volume key (backward
compatibility)

LUKS2 devices use kernel keyring for volume key by default, but user may
have overridden the default by --disable-keyring option during
cryptsetup open command.

Regards
Ondrej

[Ondrej Kozina]

Post by Ondrej Kozina

Post by Andrius Å tikonas
So if I understand correctly it will never ask for passphrase in LUKS1
case but it will always ask in LUKS2 case.

Not always for every LUKS2 device. It will always ask for a passphrase
if the volume key is passed via kernel keyring (hence the cryptsetup
status cmd for detection).
LUKS1 devices doesn't use kernel keyring for volume key (backward
compatibility)
LUKS2 devices use kernel keyring for volume key by default, but user may
have overridden the default by --disable-keyring option during
cryptsetup open command.

And don't forget not every kernel has dm-crypt kernel keyring support
available. We detect dm-crypt version runtime so you may encounter LUKS2
devices with hexbyte key in dm table directly, especially in enterprise
or more conservative distributions. I'd recommend to stick with
cryptsetup status cmd for detection though.

O.