1

How can I securely mount an encrypted container?

I want to encrypt a bunch of small files (let's say my diary). When locked, this should appear as a single file with unreadable contents. When I unlock it, it should be mounted as a file system showing the files and directories inside with a shell opened at the root of the container. The shell should be able to run regular programs like ls, cat, gedit or git. When the shell exits, the container should be unmounted as well. However, even while the container is mounted, it should not be possible for other processes to see its contents - only the shell and its child processes should be able to do this.

Is there a way to accomplish this?

Bagalaw
  • 945

1 Answers1

1

I assume you already have a container set up via LUKS. If not, create an empty file using fallocate (not smaller than 100MB), then proceed to cryptsetup luksFormat it like you'd normally set up a LUKS volume.


It's (somewhat) possible if you have root privileges; not if you're trying to protect it against someone else who has root on the system.

The simplest way to isolate file access is to have the container's files be owned by a dedicated user account – the the isolated shell you describe could be opened using su otheruser. However, I would instead recommend a full login, i.e. having two graphical sessions running side-by-side – your normal account on Ctrl-Alt-F1, your "private diary" account on Ctrl-Alt-F2 – as this would be less hassle trying to grant su access to your "host" X11 or Wayland display.

A separate graphical session also has the advantage of avoiding clipboard leaks (e.g. accidentally pasting journal contents into Stack Exchange post), and more importantly – preventing processes on the "host" account from snooping your screen contents and keyboard input, which isn't a problem in Wayland sessions but is trivial in X11. Even if an "outside" process cannot access the file currently loaded into gedit, it can simply screenshot the gedit window.

(Finally, it lets you have different GUI themes for the two environments to avoid confusion.)

The built-in "fscrypt" file encryption feature in ext4 also keeps track of loaded keys per UID.


Another method would be to create a new mount namespace using unshare, as mounts done within a namespace can be made invisible to processes in the "parent" namespace. (It's the exact same mechanism that containers such as Flatpak or Docker use to avoid polluting the host OS mount list.)

outer$ sudo cryptsetup luksOpen ... myluksvol
outer$ sudo unshare --mount --propagation=private su - $USER
  inner$ sudo mount /dev/mapper/myluksvol ~/mnt

(Exiting all processes that are in the namespace will automatically unmount everything that was visible only to that namespace, so mounts will not get "lost".)

One problem you will have is that many graphical programs, such as gedit, will start not as child processes of the shell but indirectly as children of your session's dbus-daemon or systemd --user service manager, and will therefore be outside the namespace. (Although gedit specifically has the -s --standalone option to disable this.)

To avoid this, you would need to start a whole new D-Bus session bus using dbus-run-session within the shell, but this can have its own problems. (For example, the "dconf" service used by GNOME to serialize writes to the GSettings database assumes that only one instance of the service will be running. Having a second session bus with a second dconf instance might corrupt the GSettings database.)