[pkg-cryptsetup-devel] Bug#552273: Bug#551540: cryptsetup fails when EUID != UID

Milan Broz mbroz at redhat.com
Fri Jan 15 09:58:39 UTC 2010


>> reassign 551540 cryptsetup 2:1.1.0~rc2-1

>> It seems that "cryptsetup luksOpen" fails when EUID != UID.  In
>> particular, this happens when it is run by pmount which is suid (I
>> assume that the reporters above ran pmount as non-root).  If cryptsetup
>> is run directly, then it works, because necessarily you become root
>> before running cryptsetup; if I become root before running pmount, then
>> also everything works.

Because there are still open bugs, let me explain the real source of problem:

- in previous versions (cryptsetup <= 1.0.7) gcrypt was used only for plain device
hash and did not need initialise gcrypt library properly.

- since 1.1.0* all crypt functions are implemented through gcrypt and
gcrypt is properly initialised including secure memory (gcry_control (GCRYCTL_INIT_SECMEM...)

Unfortunately, there is "feature" in libgcrypt which drops some privileges
after initialisation of that secure memory, in particular

 - it drops UID if UID and EUID differ
 - it drops all capabilities if gcrypt is linked to libcap (not an issue in Debian for now)

Suggested workaround (use own memory allocator) is not possible in FIPS mode,
and upstream cryptsetup uses gcrypt to be FIPS compliant if needed.

(pmount workaroud currently uses UID=EUID=0 when calling cryptsetup as workaround AFAIK)

Anyway, I think that this is bug in libgcrypt, such side effect is not expected when running
from privileged application like cryptsetup and there is no way how to switch it off by default.

For more info see upstream cryptsetup bug
http://code.google.com/p/cryptsetup/issues/detail?id=47

and also libgcrypt upstream bug ("This is not a bug but a feature.")
https://bugs.g10code.com/gnupg/issue1181

Milan





More information about the pkg-cryptsetup-devel mailing list