[dm-crypt] cryptsetup --test-passphrase requires root

[dm-crypt] cryptsetup --test-passphrase requires root

[Frank Cusack]

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

cryptsetup 1.6.1

cryptsetup --test-passphrase luksOpen /path/to/image

(note: /path/to/image is not a device path) complains

Cannot use a loopback device, running as non-root user.

Given that the header can be dumped without being root, it seems true that
one should be able to test the passphrase without being root, as long as
you can access the header/image.

I can see in lib/device_utils.c`device_internal_prepare that indeed,
cryptsetup makes this check proactively rather than just failing somewhere
else. In the case of --test-passphrase, is this really needed?

I don't think that is the code path for --test-passphrase though, since
--test-passphrase doesn't require a device path whereas the referenced code
does seem to require it. I didn't search exhaustively for that error
message, just stopped at the first place where it seems superfluous.
Couldn't a process have a mount capability without being uid 0?

[-- Attachment #2: Type: text/html, Size: 1265 bytes --]

Re: [dm-crypt] cryptsetup --test-passphrase requires root

[Milan Broz]

On 21/09/18 00:57, Frank Cusack wrote:
> cryptsetup 1.6.1
> 
> cryptsetup --test-passphrase luksOpen /path/to/image
> 
> (note: /path/to/image is not a device path) complains
> 
> Cannot use a loopback device, running as non-root user.
> 
> Given that the header can be dumped without being root, it seems true that one should be able to test the passphrase without being root, as long as you can access the header/image.
> 
> I can see in lib/device_utils.c`device_internal_prepare that indeed, cryptsetup makes this check proactively rather than just failing somewhere else. In the case of --test-passphrase, is this really needed?
> 
> I don't think that is the code path for --test-passphrase though, since --test-passphrase doesn't require a device path whereas the referenced code does seem to require it. I didn't search exhaustively for that error message, just stopped at the first place where it seems superfluous. Couldn't a process have a mount capability without being uid 0?

It is not so easy as you think. The keyslot must be decrypted and for that it need kernel crypto.

If there kernel userspace crypto API available, cryptsetup does not need loopback files, nor access to device-mapper ioctl (both requires root)
and --test-passphrase works with normal user account.

Just please use recent crypsetup (version 1.6.1 is 5 years old!)

But if the the crypto API is not available - basically af_alg and other kernel modules - we have to use fallback
through dm-crypt for keyslot decryption and that require loop device mapping.
Boot is root (CAP_SYSADMIN) only. This is limitation outside of cryptsetup.

Milan

Re: [dm-crypt] cryptsetup --test-passphrase requires root

[Frank Cusack]

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

Ah. Thanks for the detailed response.

Yes, I know, ancient. Unfortunately I have to support an older system here
for a few more months.

On Thu, Sep 20, 2018 at 11:57 PM, Milan Broz <gmazyland@gmail.com> wrote:

> On 21/09/18 00:57, Frank Cusack wrote:
> > cryptsetup 1.6.1
> >
> > cryptsetup --test-passphrase luksOpen /path/to/image
> >
> > (note: /path/to/image is not a device path) complains
> >
> > Cannot use a loopback device, running as non-root user.
> >
> > Given that the header can be dumped without being root, it seems true
> that one should be able to test the passphrase without being root, as long
> as you can access the header/image.
> >
> > I can see in lib/device_utils.c`device_internal_prepare that indeed,
> cryptsetup makes this check proactively rather than just failing somewhere
> else. In the case of --test-passphrase, is this really needed?
> >
> > I don't think that is the code path for --test-passphrase though, since
> --test-passphrase doesn't require a device path whereas the referenced code
> does seem to require it. I didn't search exhaustively for that error
> message, just stopped at the first place where it seems superfluous.
> Couldn't a process have a mount capability without being uid 0?
>
> It is not so easy as you think. The keyslot must be decrypted and for that
> it need kernel crypto.
>
> If there kernel userspace crypto API available, cryptsetup does not need
> loopback files, nor access to device-mapper ioctl (both requires root)
> and --test-passphrase works with normal user account.
>
> Just please use recent crypsetup (version 1.6.1 is 5 years old!)
>
> But if the the crypto API is not available - basically af_alg and other
> kernel modules - we have to use fallback
> through dm-crypt for keyslot decryption and that require loop device
> mapping.
> Boot is root (CAP_SYSADMIN) only. This is limitation outside of cryptsetup.
>
> Milan
>

[-- Attachment #2: Type: text/html, Size: 2459 bytes --]