Sstrhsrtj

I have made full disk encryption on my hard disk exactly as in this guide

https://web.archive.org/web/20180428191153/http://thesimplecomputer.info/full-disk-encryption-with-ubuntu

Partition table: GPT

Options: cryptsetup luksFormat --cipher serpent-xts-plain64 --key-size 512 --hash sha512

I have 4 encypted partitions: root,swap,home,workspace and unencrypted BIOS boot. At boot time when I type my password and when I am inside the OS all 4 partitions are mounted and unlocked. All the partitions have the same password.

Out of curiosity I locked and unmounted partition "workspace" through the ubuntu Disks app, the contents disappeared and it became like an empty partition while being viewed from Nautilus. After that I wrote a simple text file inside with some random words. I did it by opening gedit GUI, wrote some text inside then saved the file as New text file inside the locked partition. More precisely, after I unmount and lock the partition from Disks in ubuntu. I open Nautilus and navigate to /root/workspace. it shows its empty, I right click and press create new text file then open with Gedit wrote something inside save and close. Then Back in disks I unlock and mount and write my password then navigate through nautilus again to /root/workspace and I see my encrypted files all of them working.

Then I mounted and unlocked the partition and the files inside appeared again, all of them were working and non corrupted. After that I wrote around 10 GB of files inside the encrypted partition(Did this by just copy pasting a few files that already existed inside this partition with a different name) and then unmounted and locked it again. For my surprise the text file was still there, it wasn't corrupted and contained the same words untouched.

Now my questions regarding this scenario

1. Did this break the FDE in some way and did it create some new surface for attack? Since my root,swap and home were mounted and I wrote in the clear inside volume workspace did this somehow compromise and could lead to reveal of the password which was used in the other partitions too?




2. As far as I red Luks header is in the beginning of each partition, when I wrote a file inside the unmounted locked partition, how didn't it become corrupted? Should that file overwrite the Luks header or parts from the encrypted files? Instead all the files were intact and I could mount and unlock again.




3. The vice versa from question 2. When I wrote 10GB of files inside the unlocked and mounted partition shouldn't they have overwritten that unencrypted text file? Instead when I locked and unmounted it, the file withe the string was right there intact.




4. Is the guide which I used correct or there are things not mentioned and leave me vulnerable in some way?

When you “unlock” the encrypted volume, this actually does two things:

1. The content of this encrypted volume is made available to the system as a block device. Think of a block device as a disk or partition, possibly a virtual one.


2. This virtual disk happens to contain a filesystem, and the filesystem is mounted to the directory /root/workspace. ”Mounting” means that the filesystem becomes visible under that directory.

You unlocked the encrypted volume, then wrote a file to /root/workspace. At the point when you wrote this file, /root/workspace was an ordinary directory on the root partition, it didn't have anything mounted to it. So you just wrote a file to the root partition. It didn't affect the encrypted volume because there was no relationship between /root/workspace and the encrypted volume.

When you mounted the encrypted filesystem to /root/workspace, that hid the file that was in this directory. It didn't remove the file, it just made it temporarily inaccessible.

If you wanted to overwrite the encrypted volume, you'd have to access it directly. You can't do this directly from Gedit because it can only write to a filesystem, it can't write to a disk or to a partition directly. You could to it from the command line with something like echo BREAK IT >/dev/sda99 (sda99 is just an example). You'd need to run this as root, and to find the right name to put instead of sda99. The output of findmnt contains the right name. Obviously you should be very careful here, because if you do this it will break your encrypted volume, and if you do it on the wrong volume it is likely to make that volume unusable.

On a well-configured system, you shouldn't be able to write to a directory that's designated as a system mount point: /root/workspace should be writable by root only and you shouldn't work as root. (Note that the permissions on /root/workspace only matter when there is nothing mounted on the directory: mounting hides the contents of the directory, including the directory itself.) This way there would be no risk to accidentally save something on a different partition from the one you intended: you would get a “permission denied” error. To fix the partitions on /root/workspace, you can use the following command while /root/workspace is not mounted:

sudo chmod 755 /root/workspace; sudo chown root:root /root/workspace

Incidentally, note that /root is a very unusual place for a mount point. /media/workspace would be more usual for a volume that is mounted temporarily, and either /media/workspace or /workspace or just making it /home for a volume that's mounted all the time.

Also potentially of interest, if you've lost track whether a file is on an encrypted volume of not, here's how you can tell from the command line. (There must be a way in Nautilus as well, maybe even in the Gnome file opening dialog, but I'm not familiar with it.)

df /path/to/file

findmnt

The command df shows how much disk space is free on the volume containing /path/to/file — df stands for ”disk free“. It also shows the volume name and its mount point. Depending on your volume organization, this may be enough to tell. If it isn't, look up the volume in the output of findmnt to see if it's a subvolume of an encrypted volume.