Encrypted volume/filesystem support

[ShutdownRepo]

The needs

No response

Description

It'd be awesome to interface with LUKS or similar alternatives to handle encrypted volumes. This would be an option at the creation of the container, to have the workspace volume (and possibly the other part of the container filesystem) encrypted with LUKS (or something else) and a key set by the user.

It would look like this at the creation of a new container

1. exegol start container image --luks
2. wrapper asks for the symmetrical key
3. wrapper creates and mounts the volume(s) (workspace, and container fs if possible)

It would look like this at the start of an existing container

1. exegol start container image --luks
2. wrapper mounts the encrypted volumes
3. asks for the key and decrypts them

Open to suggestions

Alternatives

No response

Additional context

No response

[ShutdownRepo]

We have a first issue regarding the container's own filesystem. I'm putting this topic aside at the moment, in order to focus on encrypting volumes (i.e. the private workspace).

Using Cryptsetup

I think we could use cryptsetup for that purpose.

At container creation

1. create an empty container of a defined size
2. format (i.e. encrypt) the container with cryptsetyp luksFormat, and a key set by the user interactively
3. unlock the container with cryptsetup luksOpen
4. format the volume with mkfs.ext4
5. mount it on the host and map the target dir to the docker container mounts

At container start

Steps 3 and 5

At container stop

1. Unmount the volume
2. Lock it with cryptsetup luksClose

Problems

There are multiple problems with this solution:

• I think I can't install and use cryptsetup on macOS. We would probably need a specific workflow for macOS (and Windows WSL?)
• cryptsetup luksFormat, cryptsetup luksOpen, mount require elevated (sudo) mode. Can we have a temporary elevated context in the Python execution flow?

Going further

• we could probably skip the step of mounting the unlocked volume at container start, and only unlock it and specify the /dev/mapper/CONTAINER path to the container volumes 🤷
• I started a proof-of-concept with a passphrase scenario, but we could also implement it with a keyfile, FIDO2, whatever.

Closing thoughts, I started a PoC with cryptsetup for encrypting private workspace volumes, but it's a work in progress, there may be better, more generic (cross-OS) solutions out there. Happy to discuss it Also no idea yet if and how to encrypt the container's whole filesystem (volumes/mounts apart)

[Dramelac]

You must run the cryptsetup command from the container itself, not from the host for many reason.

[ShutdownRepo]

Okay, according to our meeting today, let's work as follows:

• host creates the file
• at container creation, with mount capabilities and the file mounted, the container fills the file with data up to a specified size and then proceeds to luksFormat, luksOpen, mkfs.ex4, and mount.
• at container stop, the LUKS formatted file (a.k.a. LUKS container) is umounted and luksClosed.
• at container start, the LUKS container is luksOpened and mounted.

A standard, shared, workplace is then replaced with an LUKS container that only the exegol container decrypts, opens and mounts. A compromised host would compromise the integrity and confidentiality of the LUKS container (e.g. if an attacker gets to use docker, is root, etc.) but it would still provide with an optional security improvement.

This feature will probably require a better entrypoint.sh, able to ask for user input, return some values, etc. Putting it on hold at the moment. Until then, we could make some progress with the backup feature.

[ShutdownRepo]

Food for thought, let's also study the ability to support FIDO2 tokens.

• https://www.guyrutenberg.com/2022/02/17/unlock-luks-volume-with-a-yubikey/
• https://0pointer.net/blog/unlocking-luks2-volumes-with-tpm2-fido2-pkcs11-security-hardware-on-systemd-248.html
• https://unix.stackexchange.com/questions/683578/luks-with-fido2-and-password

[Dramelac]

Another solution might be gocryptfs: https://wiki.archlinux.org/title/Gocryptfs

[ShutdownRepo]

Interesting option !

Another solution might be gocryptfs: https://wiki.archlinux.org/title/Gocryptfs