diff options
| -rw-r--r-- | README.md | 65 |
1 files changed, 46 insertions, 19 deletions
@@ -173,6 +173,10 @@ To check whether the needed option is enabled in your kernel, run: zgrep -h ENCRYPTION /proc/config.gz /boot/config-$(uname -r) | sort | uniq ``` +It is also recommended to use Linux kernel v5.4 or later, since this +allows the use of v2 encryption policies. v2 policies have several +security and usability improvements over v1 policies. + Be careful when using encryption on removable media, since filesystems with the `encrypt` feature cannot be mounted on systems with kernel versions older than the minimums listed above -- even to access unencrypted files! @@ -241,9 +245,10 @@ The fields are: for more details about the supported algorithms. * "policy\_version" is the version of encryption policy to use. - The choices are "1" and "2". Directories created with policy - version "2" are only usable on kernel v5.4 or later, but are - preferable to version "1" if you don't mind this restriction. + The choices are "1" and "2". If unset, "1" is assumed. + Directories created with policy version "2" are only usable on + kernel v5.4 or later, but are preferable to version "1" if you + don't mind this restriction. * "use\_fs\_keyring\_for\_v1\_policies" specifies whether to add keys for v1 encryption policies to the filesystem keyring, rather than to @@ -773,27 +778,49 @@ manifest in other ways such as Docker containers being unable to access encrypted files, or NetworkManager being unable to access certificates if they are located in an encrypted directory. -If you are using kernel v5.4 or later, you can fix this by setting the -following in `/etc/fscrypt.conf`: +The recommended way to fix this is by creating your encrypted +directories using v2 encryption policies rather than v1. This +requires Linux v5.4 or later and `fscrypt` v0.2.6 or later. If these +prerequisites are met, enable v2 policies for new directories by +setting `"policy_version": "2"` in `/etc/fscrypt.conf`. For example: + +``` + "options": { + "padding": "32", + "contents": "AES_256_XTS", + "filenames": "AES_256_CTS", + "policy_version": "2" + }, +``` - "use_fs_keyring_for_v1_policies": true +This only affects new directories. If you want to upgrade an existing +encrypted directory to use a v2 policy, you'll need to re-create it by +using `fscrypt encrypt` to encrypt a new empty directory, copying your +files into it, and replacing the original directory with it. -However, this makes manually unlocking and locking encrypted -directories start to require root. (The PAM module will still work.) -E.g., you'll need to run `sudo fscrypt unlock`, not `fscrypt unlock`. +In `fscrypt` v0.2.7 and later, the `fscrypt setup` command +automatically sets `"policy_version": "2"` when creating +`/etc/fscrypt.conf` if kernel support is present. -Alternatively, you can upgrade your encrypted directories to use v2 -encryption policies by setting the following in the "options" section -of `/etc/fscrypt.conf`: +__IMPORTANT:__ directories that use v2 encryption policies are +unusable on Linux v5.3 and earlier. If this will be a problem for you +(for example, if your encrypted directories are on removable storage +that needs to work on computers with both old and new kernels), you'll +need to use v1 policies instead. In this case, you can enable a +fallback option to make `fscrypt` use the filesystem keyring for v1 +policies: - "policy_version": "2" +``` + "use_fs_keyring_for_v1_policies": true +``` -... and then for each of your encrypted directories, using `fscrypt -encrypt` to encrypt a new empty directory, copying your files into it, -and replacing the original directory with it. This will fix the key -access problems, while also keeping `fscrypt unlock` and `fscrypt -lock` usable by non-root users. This is the recommended solution if -you don't need to access your files on kernels older than v5.4. +This fallback option only has an effect if the kernel supports using +the filesystem keyring. This option is also useful if you simply +don't want to re-create your old, v1 directories. However, this +option makes manually unlocking and locking encrypted directories +start to require root. (The PAM module will still work.) E.g., +you'll need to run `sudo fscrypt unlock`, not `fscrypt unlock`. Most +people should just use v2 policies instead. ## Legal |