JumpCloud administrators can create and apply a Linux Check Disk Encryption Policy to one device or group of devices, helping secure their data and sensitive information across their fleet of JC-managed Linux devices. Without this policy, an admin would need to manually track which devices require encryption and verify if they are encrypted to ensure proper data security and compliance. With JumpCloud’s Linux Check Disk Encryption Policy, admins can specify which devices to encrypt and, more specifically, if the devices require only managed home directories or full disk encryption (FDE). Once the policy is applied, the administrator will be notified if any of the targeted devices don’t meet the required encryption requirements.
- The Linux Check Disk Encryption Policy can be applied to any JC-supported Linux distribution.
- Due to the nature of Linux FDE and the need to enforce FDE during initial system configuration, disk encryption still needs to be manually enabled on the device. However, JumpCloud provides recommended disk encryption methodologies and guided instructions for encrypting your Linux systems.
- While the Linux Check Disk Encryption Policy doesn’t encrypt the data on the targeted device(s), it will notify the administrator if any of the targeted devices don’t comply with the configured policy.
- This policy supports Linux Unified Key Setups (LUKs) and fscrypt.
Linux devices can be encrypted in one of two ways:
- Full disk encryption – Encrypting the block device before it is mounted on the system.
- File-based encryption – Encrypting only a folder or file using native filesystem features.
Full disk encryption is preferred, as it ensures that the system is inaccessible without entering an encryption passphrase. Additionally, fscrypt doesn’t encrypt filesystem metadata except for filenames, whereas full disk encryption ensures everything written to the disk is encrypted. After reviewing this article, you should know how to encrypt the entire disk, as well as how to encrypt only home directories on your system.
This KB article covers:
- Full Disk (Block Device) Encryption (FDE)
- File-based Encryption
Full Disk (Block Device) Encryption (FDE)
FDE protects the data on a block device by encrypting it. To access the device’s decrypted contents, a user must provide a passphrase or key as authentication. This provides additional security beyond existing operating system security mechanisms, as it protects the device’s contents even if it was physically removed from the system. FDE is implemented using LVM (Logical Volume Management) for disk management and LUKS (Linux Unified Key Setup) encryption in all modern distro installer wizards.
As a system administrator, you can encrypt your device's storage devices using LUKS, which is a specification for block device encryption. It establishes an on-disk format for the data, as well as a passphrase/key management policy.
LUKS uses the kernel device mapper subsystem with the dm-crypt module. This arrangement provides a low-level mapping that handles encryption and decryption of the device data. You can use the cryptsetup utility to perform user-level operations such as creating and accessing encrypted devices.
What LUKS Does
- Encrypts entire block devices, making it well-suited for protecting the contents of mobile devices, such as removable storage media or laptop disk drives.
- Encrypts swap devices due to underlying contents of the encrypted block device being arbitrary. This is also convenient with certain databases that use specially formatted block devices for data storage.
- Uses the existing device mapper kernel subsystem.
- Provides passphrase strengthening, which protects against dictionary attacks.
- Allows devices to contain multiple key slots, permitting users to add backup keys or passphrases.
Note: LUKS is not well-suited for applications requiring more than eight users to have distinct access keys to the same device or file-level encryption.
In general, you can enable LUKS encryption using LVM partition management during the initial installation of your distribution of choice.
Note: For a slightly more encrypted disk, you can follow this in-depth wiki article: https://help.ubuntu.com/community/Full_Disk_Encryption_Howto_2019. However, the standard Ubuntu installer option is sufficient for most, and the tradeoff for usability is acceptable.
Ubuntu 16.04, 18.04 LTS releases:
Ubuntu 20.04 LTS:
Ubuntu 20.10 (currently unsupported by JC) and newer versions):
Note: Ubuntu supports native ZFS encryption in 20.10 and up, which is not yet supported by JC.
Note: For a slightly more encrypted disk, you can follow this in-depth wiki article: https://docs.fedoraproject.org/en-US/quick-docs/encrypting-drives-using-LUKS/. However, the standard installer option is sufficient for most, and the tradeoff for usability is acceptable.
Red Hat Enterprise Linux (RHEL)
Note: Rocky Linux uses the same installer as Fedora, CentOS, and RHEL, providing the same options.
(See note for Rocky)
CentOS 9 Stream:
(See note for Rocky)
Debian offers an installer option, as well as additional manual instructions located at: https://wiki.debian.org/Cryptsetup.
Note: For a slightly more encrypted disk, you can follow this in-depth community tutorial: https://community.linuxmint.com/tutorial/view/2265. However, the standard installer option is sufficient for most, and the tradeoff for usability is acceptable.
Amazon Linux doesn’t offer an install option, because it’s configured via cloud-init and options within the AWS Console. However, you can use encrypted Elastic Block Store (EBS) block devices to back your EC2 instances by following the instructions at the following sites:
Note: the JumpCloud console doesn’t currently recognize encrypted EBS volumes, as they appear as regular block devices from within the instance where the agent runs.
If you don’t want to completely wipe your machine, but just encrypt your home directory (folders), you can use fscrypt. This is another built-in feature of the Linux kernel and the ext4, F2FS, and UBIFS file systems.
The absolute minimum required Linux kernel version to use fscrypt is 4.15, however, it is highly recommended for the kernel version to be 5.4 or later, as this allows the use of v2 encryption policies. There are several security and usability issues with v1 encryption policies, meaning you may not be able to use fscrypt for home directories on older versions. The latest releases of most distributions include a recent enough kernel, starting with the following versions:
- CentOS 9
- Debian 11
- Fedora 32
- Linux Mint 20.2
- Red Hat Enterprise Linux 9.0
- Ubuntu 20.04 LTS
Additionally, older distribution versions may not have a new enough version of fscrypt to take advantage of the kernel features. It is recommended that you start with an up to date version of the distribution you intend to use, and that the version of the fscrypt userspace tool (described later) is at least 0.2.4.
Fscrypt is available on ext4, which is the most widely used file system for Linux. It’s also available on F2FS and UBIFS, which are less frequently used file systems. These are used on Android and Chrome operating systems.
Fourth Extended File System (ext4)
For ext4, the file system on which encryption should be used must have the encrypt feature flag enabled. To enable it, run: # tune2fs -O encrypt /dev/device.Warning: Once the encrypt feature is enabled, Linux versions older than 4.1 will be unable to mount the file system. Also, Linux versions older than 5.5 will be unable to mount the file system if its block size (tune2fs -l /dev/device | grep 'Block size') differs from the system page size (getconf PAGE_SIZE). Normally, both are 4096, which shouldn’t be a problem.
- The operation can be undone with debugfs -w -R “feature -encrypt” /dev/device. Run fsck before and after to ensure the integrity of the file system.
- When creating a new file system, one can enable the encrypt feature immediately with mkfs.ext4 -O encrypt.
This fscrypt tool is used to interact with encrypted folders on the system as a user using the following steps:
- Install the fscrypt package and the pam module. Ensure that the version installed is 0.2.4 or greater. If not, you will be able to encrypt files and folders with fscrypt, but will have problems if you attempt to encrypt home directories. If you’re not able to update your base system to at least the versions specified above in the Kernel section, proceed to follow the manual build in step 1.b. below.
- For Ubuntu and other Debian-based distributions, install the official packages:
sudo apt install fscrypt libpam-fscrypt
- For Fedora and other Red Hat-based distributions (e.g., CentOS), follow the manual build and installation steps here: https://github.com/google/fscrypt#building-and-installing.
- Then run: # fscrypt setup. This creates the file /etc/fscrypt.conf and the directory /.fscrypt.
- If the file system on which encryption is to be used is not the root file system, run: # fscrypt setup mountpoint
(Where mountpoint is where the file system is mounted (e.g., /home)).
This creates the directory mountpoint/.fscrypt to store fscrypt policies and protectors.
Warning: Never delete the .fscrypt directory. Otherwise, ALL access to encrypted files will be lost.
The fscrypt PAM integrates encrypted folders with the Linux Pluggable Authentication module system.
Adjust the system PAM configuration to enable pam_fscrypt, unlocking login passphrase-protected directories automatically at login and keeping login passphrase-protected directories in sync with changes to the login passphrase.
Note: Installing libpam-fscrypt on Ubuntu and other Debian-like systems handles the necessary file modifications in:
To automatically apply these defaults:
- Run sudo pam-auth-update.
- Follow the on-screen instructions.
To make the modifications manually for Red Hat-based systems, follow the instructions here: https://github.com/google/fscrypt#setting-up-for-login-protectors, and summarized below:
- Append the following line to the auth section in /etc/pam.d/login:
auth optional pam_fscrypt.so
- Append the following lines before session include system-auth in the session section of /etc/pam.d/login:
session [success=1 default=ignore] pam_succeed_if.so service = systemd-user quiet
session optional pam_fscrypt.so drop_caches lock_policies
Note: The first line, taken from https://github.com/google/fscrypt/issues/95, is a bypass for the systemd --user session, which doesn't properly close its PAM session and would otherwise block the locking on logout.
- Append the following line to /etc/pam.d/passwd:
password optional pam_fscrypt.so
- Login protectors are only as secure as the system’s passphrase hashing in /etc/shadow. Before using a login protector, follow these security recommendations.
- If a user’s home directory is encrypted, SSH for that user may not work until their home directory has been unlocked. To mitigate this, you must ensure that the PasswordAuthentication setting is enabled in SSH config.
Complete the following steps to encrypt a user's home directory:
- Ensure that all preparations have been completed, including enabling pam_fscrypt.
- As the root user, create a new encrypted directory for the user using the following set of commands:
# mkdir /home/newhome
# chown USERNAME:USERGROUP /home/newhome
# fscrypt encrypt /home/newhome --user=USERNAME
Should we create a new protector? [y/N] y
Your data can be protected with one of the following sources:
1 - Your login passphrase (pam_passphrase)
2 - A custom passphrase (custom_passphrase)
3 - A raw 256-bit key (raw_key)
Enter the source number for the new protector [2 - custom_passphrase]: 1
Enter login passphrase for USERNAME:
"/home/newhome" is now encrypted, unlocked, and ready for use.
- Select the option to create a new protector and to protect the directory with the user’s login passphrase.
- Copy the contents of the user’s old home directory into the encrypted directory:
# cp -a -T /home/user /home/newhome
Tip: If there is not enough disk space for a second copy of the home directory, consider using mv -T /home/user /home/newhome instead. However, it’s strongly recommended that you make a backup first.
- If the cp method was used, check whether the directory is being automatically unlocked on login before using it. The simplest way to do this is to:
- Reboot and log in as that user.
- Run: $ fscrypt status /home/newhome
Note: The following are the outputs of the command:
"/home/newhome" is encrypted with fscrypt”.
Options: padding:32 contents:AES_256_XTS filenames:AES_256_CTS policy_version:2
Protected with 1 protector:
PROTECTOR LINKED DESCRIPTION
ef25588cbd49f90a No login protector for testuser
- If it says Unlocked: No, then something is wrong with the PAM configuration, or the incorrect type of protector was selected.
- Delete the directory and start again from mkdir /home/newhome.
- Otherwise, replace the home directory:
# mv /home/user /home/oldhome
# mv /home/newhome /home/user
- If everything is working as expected, delete the old home directory:
# find /home/oldhome -type f -print0 | xargs -0 shred -n1 --remove=unlink
# rm -rf /home/oldhome
Tip: Running shred is optional but strongly recommended.