On Fri, Jan 23, 2015 at 23:23:16 CET, Sven Eschenberg wrote:
> On Fri, January 23, 2015 22:33, Ahmed, Safayet (GE Global Research) wrote:
> > I've been looking into the cryptsetup tool and I just wanted to mention
> > some
> > bugs/undocumented features I came across.
> >
> > 1 detached headers
> > ------------------
> >
> > For a Luks setup that uses a detached header, a lot of the cryptsetup
> > commands
> > don't work in an intuitive way. Specifically, the "--header" option is
> > ignored
> > and cryptsetup throws an error that the specified device is not a Luks
> > device.
> > The cryptsetup commands work when the path to the actual luks device is
> > replaced with the path to the header file. This was the case for the
> > following
> > commands:
> >
> > luksDump
> > luksAddKey
> > luksKillSlot
> >
> > I didn't check for the other commands. If this is the intended behavior, I
> > think it should be mentioned in the doucmentation that the header file
> > should
> > be used in place of the <device> argument in the case of detached LUKS
> > headers.
>
> Operations on the HEADER naturally require the header and not the actual
> payload. It would be redundant to pass the payload (device) and naturally
> the header is the only (direct) parameter. Should this be mentioned more
> clearly in the docs/manpage? Possibly yes.
While this is obvious behavior if you have the LUKS data model
in mind, I think it is a valid criticism of the documentation.
I will make this more obvious in the man-page and maybe add an
FAQ-item. May take a week or two though, I currently have a lot
of work.
> >
> >
> > 2 master-key-file with new-key-file
> > -----------------------------------
> >
> > For the luksAddKey command, when the "--master-key-file" argument is
> > specified,
> > the new-key-file positional argument is ignored. Whether or not a file is
> > provided for the new pass phrase, the user is prompted to enter a pass
> > phrase.
>
> I think I reported this quite a while back and it was supposedly fixed
> some while ago (2010 IIRC).
This code seems to still be in 1.6.5, but starting at line 955.
> >
> > The problem is in the implementation of the function "action_luksAddKey"
> > in
> > "src/cryptsetup.c". Consider the following lines (916 - 927):
> >
> > if (opt_master_key_file) {
> > r = _read_mk(opt_master_key_file, &key, keysize);
> > if (r < 0)
> > goto out;
> > //FIXME: process keyfile arg
> > r = crypt_keyslot_add_by_volume_key(cd, opt_key_slot,
> > key, keysize, NULL, 0);
> > } else if (opt_key_file || opt_new_key_file) {
> > r = crypt_keyslot_add_by_keyfile_offset(cd, opt_key_slot,
> > opt_key_file, opt_keyfile_size, opt_keyfile_offset,
> > opt_new_key_file, opt_new_keyfile_size, opt_new_keyfile_offset);
> > } else {
> >
> > When the master key is present, the code doesn't check "opt_new_key_file"
> > and
> > assumes that the user should be prompted for the pass phrase.
> >
> > Is this the intended behavior of luksAddKey?
I think this is actually a defect. It is a minor one, as using
the master-key is an emergency-only operation and hence likely
done manyally anyways. But if I am right and it is a defect, it
should probably get an item on the issues-list.
Gr"usse,
Arno
> > regards,
> >
> > Safayet Ahmed
> > _______________________________________________
> > dm-crypt mailing list
> > dm-crypt@xxxxxxxx
> > http://www.saout.de/mailman/listinfo/dm-crypt
> >
>
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@xxxxxxxx
> http://www.saout.de/mailman/listinfo/dm-crypt
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato
If it's in the news, don't worry about it. The very definition of
"news" is "something that hardly ever happens." -- Bruce Schneier
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
