View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005373||Kali Linux||[All Projects] Feature Requests||public||2019-03-29 10:19||2020-12-01 10:48|
|Target Version||2019.2||Fixed in Version||2019.3|
|Summary||0005373: Replace cryptsetup nuke passphrase with a dedicated system service|
|Description||The feature described in https://www.kali.org/tutorials/nuke-kali-linux-luks/ relies on a custom C patch of cryptsetup that we are carrying and updating over time. Maintaining this patch can be very hard at times. Right now, I have spent more than a day to try to implement the feature for the luks2 format which is the new default format used by cryptsetup 2.1.0 and I'm not done yet.|
To avoid this regular work, I wanted to work with upstream on this feature and get it merged. Thus I opened https://gitlab.com/cryptsetup/cryptsetup/issues/447 and I got a clear answer that this was not going to be merged in any form. But upstream also suggested that we should create some system service calling "cryptsetup luksErase" to provide the same feature. This ticket is about this idea.
|Additional Information||I believe that this is a good idea and that we should pursue it. If the "nuke password" use case is mainly a quick & easy way to wipe everything on early boot, then we can imagine extending the initramfs with a hook that would scan the kernel command line for "cryptsetup-nuke=yes" and that would erase the luks header in that case... we could even add a new grub menu entry in the advanced menu to make it more accessible (with a "cryptsetup-nuke=ask" parameter that would require an explicit confirmation before erasing anything to avoid accidental selection of the menu entry). However we would loose the authentication brought by the nuke password since anyone with access to the machine could wipe the luks header (but I guess as soon as anyone is in a position to access the machine and reboot it, he can destroy it in many other ways).|
Such a feature can be implemented in an entirely separate kali-specific package and it would be easier to maintain over time. Opinions ?
||It seems that creating an advanced grub menu entry is the only practical way to do this going forward. The nuke feature, while cool, has a pretty limited use-case so I don't think it's worth the effort of you fighting with it.|
I'd like not to lose this function.
It's really unique, I did not meet the one in any other distributive. I use it in my daily routine and I know it very well.
So I created "cryptsetup-nuke-password" as a separate package hijacking the cryptsetup password prompt in the initramfs. That will let us switch to an unmodified cryptsetup.
See https://gitlab.com/kalilinux/packages/cryptsetup-nuke-password for details.
The new cryptsetup and the new cryptsetup-nuke-password package are both in kali-experimental. Feel free to test them.
I wonder what else needs to happen before I can move them to kali-dev... I guess we want to update https://www.kali.org/tutorials/nuke-kali-linux-luks and the sidebar in the book (cf end of https://kali.training/topic/adding-persistence-to-the-live-iso/).
Do we want to modify cryptsetup so that luksAddNuke prints an informative error message directing users to the new package ?
I updated cryptsetup 2.1.0-5kali1 in kali-experimental to print a warning:
$ cryptsetup luksAddNuke foobar
ERROR: 'cryptsetup luksAddNuke' is deprecated.
Instead use the feature provided by the cryptsetup-nuke-password package:
sudo apt install cryptsetup-nuke-password
sudo dpkg-reconfigure cryptsetup-nuke-password
And the package has a recommends on cryptsetup-nuke-password. cryptsetup-nuke-password is now in kali-rolling as well.
Kali Revealed book updated with commit a5fe5bd88d9e04a070ba38d40f16260799703777 and asked digip to update its online copy.
Now on the website, there are at least two articles that need to be updated to document the new cryptsetup-nuke-password feature:
||The websites have been updated, the packages have been pushed to kali-rolling. Nothing left to do here.|
|2019-03-29 10:19||rhertzog||New Issue|
|2019-03-29 10:19||rhertzog||Status||new => assigned|
|2019-03-29 10:19||rhertzog||Assigned To||=> rhertzog|
|2019-03-29 10:37||rhertzog||Description Updated||View Revisions|
|2019-03-29 14:40||dookie||Note Added: 0010458|
|2019-04-19 11:37||Dober||Note Added: 0010527|
|2019-06-14 19:35||rhertzog||Note Added: 0010695|
|2019-06-25 09:51||rhertzog||Note Added: 0010738|
|2019-06-25 12:03||rhertzog||Note Added: 0010741|
|2019-07-08 14:38||rhertzog||Status||assigned => resolved|
|2019-07-08 14:38||rhertzog||Resolution||open => fixed|
|2019-07-08 14:38||rhertzog||Fixed in Version||=> 2019.3|
|2019-07-08 14:38||rhertzog||Note Added: 0010769|
|2020-12-01 10:48||g0tmi1k||Priority||high => normal|