Public bug reported:
Binary package hint: cryptsetup
I would like to suggest a modification that would allow someone to have
multiple keyscript entries in crypttab. In addition there should also be an
added keystdout filed and also multiple key fields (for each keyscript one).
All the keyscripts would then be executed (if written in "pseudo-bash") in such
order:
$keyscript1 $key1 >& $keystdout1 | $keyscript2 $key2 >& $keystdout2 |
$keyscript3 $key3 >& $keystdout3 | ... | $keyscriptN $keyN
Where each keyscript could read what any of the previous keyscripts has written
to his "stdout" file descriptor.
Something like this would allow chaining of different keyscripts, redirecting
their output and using it in other scripts. It would then give the user ability
to create more complex and easily changable authentication procedures.
Eg. with Debian/Ubuntu scripts: running askpass to get a hashed passphrase,
running passdev to get a keyfile from an USB stick, and then running a script
that XORs this two values and outputs the final key used for decryption.
ALTERNATIVE:
Similar functionality could also be implemented in a special keyscript, that
would accept as parameters all other keyscripts with arguments it should run
and combine their output as described above.
But the reason I am proposing the first solution is because of
"arguments-hell" in current crypttab file format. Think about a
keyscript that wants to get as an argument another keyscript with its
arguments (complication variant: ..with its arguments that also contain
other keyscripts with arguments). In currect crypttab format all this
arguments should be put in the key field and mustn't contain any
whitespaces. How should then the first keyscript recognize and split its
arguments? Lets assume it uses a comma to separate its own arguments,
but what should then the second script use as its input separator
(whitespaces and commas don't appear anymore)?
This then leads to the conclusion that the crypttab file format needs to change
to solve this! Altough this would break backward-compatibility I would like to
suggest the removal of key field that should be replaced with a type+encryption
options (without keyscript) followed by <keyscript>
[<arguments_for_keyscript>]* (it could also be done without this changes, but
then it just becomes ugly). In this additional (or maybe all) fields " and '
qoutes should be parsed as it is usual in *nix world (this is the important
change!).
With all this in mind the example described above would look something like:
sdaX_crypt /dev/sdaX swap,cipher=aes-cbc-essiv:sha256,size=256,hash=ripemd160
/path/to/decrypt_xormix "/path/to/askpass" "" "/path/to/passdev"
"/dev/sdZ:/keyfile"
Or in the ugly backward-compatible variant where the keyscript needs to deal
with parsing individual arguments from the key field:
sdaX_crypt /dev/sdaX
"/path/to/askpass","","/path/to/passdev","/dev/sdZ:/keyfile"
swap,cipher=aes-cbc-essiv:sha256,size=256,hash=ripemd160,keyscript=/path/to/decrypt_xormix
And a simple luks entry would just become a little shorter:
sdaX_crypt /dev/sdX luks
And the corresponding conf.d/cryptroot would become:
target=sdX_crypt,source=/dev/sdX,cipher=aes-cbc-essiv:sha256,size=256,hash=ripemd160,keyscript=/path/to/decrypt_xormix,keyarg1="/path/to/askpass",keyarg2="",keyarg3="/path/to/passdev",keyarg4="/dev/sdZ:keyfile"
As a consequence the script that parses cryptroot should become "quote-aware"
so that the appearing of commas (,) in quoted strings would be skipped.
In the backward-compatible variant it would then probably look like (note the
extra escaped quotes):
target=sdX_crypt,source=/dev/sdX,cipher=aes-cbc-essiv:sha256,size=256,hash=ripemd160,keyscript=/path/to/decrypt_xormix,key="\"/path/to/askpass\",\"\",\"/path/to/passdev\",\"/dev/sdZ:/keyfile\""
** Affects: cryptsetup (Ubuntu)
Importance: Undecided
Status: New
--
Multiple keyscripts in crypttab
https://bugs.launchpad.net/bugs/308392
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
