Over on the Whonix forums, I was discussing how to workaround limitations of user-sysmaint-split with a user, and discovered that they are using a paid proprietary application for file encryption:
I replied, explaining that they could use LUKS instead and could set it up with a number of tools built into the OS, but in the process realized that adding a new encrypted volume to an existing system or VM (which may or may not have full disk encryption enabled on it) is a pain:
First you have to partition the disk with parted. I expect a significant portion of our userbase doesn’t even know what a partition is.
Then you have to format a partition on the disk with cryptsetup. This is not particularly easy, especially since you now have to grapple with the details of device-mapper thanks to how LUKS works under the hood and how cryptsetup exposes that.
Then you have to open the newly created encrypted volume.
Then you have to format the encrypted volume with a filesystem using something like mkfs.ext4.
Then you have to mount that filesystem with mount.
Then you have to fix permissions on the filesystem with chown, since by default it won’t let your standard user write to it.
Then you have to add a line for the encrypted volume to /etc/crypttab using either vim or nano, which has to be done carefully to avoid breaking things, and is not intuitive at all.
Then you have to add a line for mounting the encrypted volume to /etc/fstab, which is again unintuitive and requires care.
Then you have to regenerate the initramfs with dracut (this might be optional but might not be).
Requiring users to juggle seven command-line utilities and two critical configuration files to set up a new encrypted disk seems like a lot. The steps for setting up encryption on a USB drive are similarly complicated, but you get to omit the crypttab and fstab stuff since you don’t want that automounted on boot.
There are tools that can do a lot of this already (KDE Partition manager for instance can handle drive setup, though I don’t know if it can handle addition to crypttab and fstab or not), but they are also, to my awareness, painful to use.
Given that users are resorting to proprietary software for this use case, potentially because they can’t figure out how to use the existing battle-tested open-source tools for this, it seems like we would be well served by adding some utility that can do some of this. If there’s an existing utility for this, that would be awesome, otherwise I don’t think it would be that hard to write one (famous last words). We had a utility that could do part of this in the past with zuluCrypt, but that ended up getting removed from Kicksecure due to an escalation-of-privilege vuln in a package patch and has been removed from Debian entirely for the same reason IIRC.
So will give you a use case here not being mentioned from my personal experience. Encrypted disk images or ISO’s for burning to encrypted CD/DVD backups. I like to backup keys (ssh & GPG) and hoard data and CD/DVD’s play a role as backup next to HDD. Given how if the media is R and not RW it also a security benefit.
Anyhow people often suggest to just to make compressed archive that is password protected since its AES256 and burn it. I dont think this is anywhere as strong as LUKS encrypted disk or ISO image.
Previously would use zulucrypt to meet my needs for this.
Also experimented the manual method to create the *.iso and use dd /dev/urandom to generate that first istead of parted or trucate/fallocate:
# this example creates a 4 GiB image (lots of disks are roughly 4.7GB)
# 16 MiB × 256 = 4096 MiB
dd if=/dev/urandom of=backup.iso bs=16M count=256 status=progress
Then do everything else but I would call the pcmanfm-qt to open the mounted container to copy data to it before closing it.
This made me come to the same conclusion as you if it was worth creating a new tool to do this or if there was something to fork and build off of. It wouldn’t be hard to pass cryptsetup commands to a GUI and depending on the programming lang there might already be tools that call it like with python.
Yes, unless someone already made one which is the hope.
As far as I’m aware, no (and due to my involvement in Lubuntu, I’m pretty aware of what they provide).
My knowledge of how optical media works is quite shaky, so I don’t know what all is possible here. Were you creating a LUKS volume with an ISO filesystem in it, then burning the container image directly to the disk?
I would begin by generating an .iso file using fallocate (though I later switched to /dev/urandom in an attempt to increase entropy). The process then proceeds as follows after generating a file with a .iso extension:
- Encrypt the file using cryptsetup
- Open the LUKS container
- Create a filesystem with mkfs.ext4
- Mount the container
- Adjust permissions with chown
- Transfer files into it (waiting for the process to complete)
- Close the LUKS container
Burning via Brasero
I have successfully used two methods:
- *Burn the container as a file* via a data CD option.
- *Select "Burn Disk Image"* and write the ISO directly to the disc.
With the first option, the disc does not appear as a mounted volume until you manually open the file. With the second option, inserting the CD/DVD causes the entire disc to be recognized as an encrypted volume.
This was tested on Kicksecure 17. I have not revisited the process in version 18. Now I also hope & question if disk burning software like Brasero can operate with enuff permissions due to sysmaint change?
I’ll revist this later this week when I get some time.
Hmm, sounds like you’re burning a filesystem image to the disk, but not an ISO filesystem image. ISO is a filesystem, not just a filename convention, so your “.iso” file isn’t an ISO file at all
But yes, the ability to create encrypted container images would be something I would want this tool to have. If such an image can be burned to a disc and just work, awesome.
Right but disk burning software from what I have tried wont recognize it as a ISO to burn to the disk based on the filename extension. If it was not .iso or .img regardless if it was a true ISO filesystem, the option to burn as disk image via Brasero wont allow/work. I’ll have to try mkisofs, but generally I think most burning software relies on the convention first and foremost before checking the filesystem format type.
