[dm-crypt] LUKS2 resizing

[dm-crypt] LUKS2 resizing

[Andrius Štikonas]

[-- Attachment #1: Type: text/plain, Size: 637 bytes --]

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

-- 
I encourage the use of end to end email encryption

GPG key:   https://stikonas.eu/andrius.asc
Fingerprint:  1EE5 A320 5904 BAA2 B88C 0A9D 24FD 3194 0095 C0E1

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [dm-crypt] LUKS2 resizing

[Ondrej Kozina]

On 12/13/2017 12:35 AM, Andrius Štikonas wrote:
> 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.

> 
> 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

Re: [dm-crypt] LUKS2 resizing

[Andrius Štikonas]

[-- Attachment #1: Type: text/plain, Size: 1954 bytes --]

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

2017 m. gruodžio 14 d., ketvirtadienis 10:23:21 GMT rašėte:
> On 12/13/2017 07:05 PM, Andrius Štikonas wrote:
> 
> > 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>
> 
> It prints usual status information together with line:
> "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.
> 
> 


-- 
I encourage the use of end to end email encryption

GPG key:   https://stikonas.eu/andrius.asc
Fingerprint:  1EE5 A320 5904 BAA2 B88C 0A9D 24FD 3194 0095 C0E1

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [dm-crypt] LUKS2 resizing

[Ondrej Kozina]

On 12/14/2017 08:22 PM, Andrius Štikonas wrote:
> 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

Re: [dm-crypt] LUKS2 resizing

[Ondrej Kozina]

On 12/18/2017 10:30 AM, Ondrej Kozina wrote:
> On 12/14/2017 08:22 PM, Andrius Štikonas wrote:
>> 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.