Getting started with Stratis – encryption

Stratis is described on its official website as an “easy to use local storage management for Linux.” See this short video for a quick demonstration of the basics. The video was recorded on a Red Hat Enterprise Linux 8 system. The concepts shown in the video also apply to Stratis in Fedora.

Stratis version 2.1 introduces support for encryption. Continue reading to learn how to get started with encryption in Stratis.

Prerequisites

Encryption requires Stratis version 2.1 or greater. The examples in this post use a pre-release of Fedora 33. Stratis 2.1 will be available in the final release of Fedora 33.

You’ll also need at least one available block device to create an encrypted pool. The examples shown below were done on a KVM virtual machine with a 5 GB virtual disk drive (/dev/vdb).

Create a key in the kernel keyring

The Linux kernel keyring is used to store the encryption key. For more information on the kernel keyring, refer to the keyrings manual page (man keyrings).  

Use the stratis key set command to set up the key within the kernel keyring.  You must specify where the key should be read from. To read the key from standard input, use the –capture-key option. To retrieve the key from a file, use the –keyfile-path <file> option. The last parameter is a key description. It will be used later when you create the encrypted Stratis pool.

For example, to create a key with the description pool1key, and to read the key from standard input, you would enter:

# stratis key set --capture-key pool1key
Enter desired key data followed by the return key:

The command prompts us to type the key data / passphrase, and the key is then created within the kernel keyring.  

To verify that the key was created, run stratis key list:

# stratis key list
Key Description
pool1key

This verifies that the pool1key was created. Note that these keys are not persistent. If the host is rebooted, the key will need to be provided again before the encrypted Stratis pool can be accessed (this process is covered later).

If you have multiple encrypted pools, they can have a separate keys, or they can share the same key.

The keys can also be viewed using the following keyctl commands:

# keyctl get_persistent @s
318044983
# keyctl show
Session Keyring
 701701270 --alswrv      0     0  keyring: _ses
 649111286 --alswrv      0 65534   \_ keyring: _uid.0
 318044983 ---lswrv      0 65534   \_ keyring: _persistent.0
1051260141 --alswrv      0     0       \_ user: stratis-1-key-pool1key

Create the encrypted Stratis pool

Now that a key has been created for Stratis, the next step is to create the encrypted Stratis pool. Encrypting a pool can only be done at pool creation. It isn’t currently possible to encrypt an existing pool.

Use the stratis pool create command to create a pool. Add –key-desc and the key description that you provided in the previous step (pool1key). This will signal to Stratis that the pool should be encrypted using the provided key. The below example creates the Stratis pool on /dev/vdb, and names it pool1. Be sure to specify an empty/available device on your system.

# stratis pool create --key-desc pool1key pool1 /dev/vdb

You can verify that the pool has been created with the stratis pool list command:

# stratis pool list 
Name                     Total Physical   Properties
pool1   4.98 GiB / 37.63 MiB / 4.95 GiB      ~Ca, Cr

In the sample output shown above, ~Ca indicates that caching is disabled (the tilde negates the property). Cr indicates that encryption is enabled.  Note that caching and encryption are mutually exclusive. Both features cannot be simultaneously enabled.

Next, create a filesystem. The below example, demonstrates creating a filesystem named filesystem1, mounting it at the /filesystem1 mountpoint, and creating a test file in the new filesystem:

# stratis filesystem create pool1 filesystem1
# mkdir /filesystem1
# mount /stratis/pool1/filesystem1 /filesystem1
# cd /filesystem1
# echo "this is a test file" > testfile

Access the encrypted pool after a reboot

When you reboot you’ll notice that Stratis no longer shows your encrypted pool or its block device:

# stratis pool list
Name   Total Physical   Properties
# stratis blockdev list
Pool Name   Device Node   Physical Size   Tier

To access the encrypted pool, first re-create the key with the same key description and key data / passphrase that you used previously:

# stratis key set --capture-key pool1key
Enter desired key data followed by the return key:

Next, run the stratis pool unlock command, and verify that you can now see the pool and its block device:

# stratis pool unlock
# stratis pool list
Name                      Total Physical   Properties
pool1   4.98 GiB / 583.65 MiB / 4.41 GiB      ~Ca, Cr
# stratis blockdev list
Pool Name   Device Node   Physical Size   Tier
pool1       /dev/dm-2          4.98 GiB   Data

Next, mount the filesystem and verify that you can access the test file you created previously:

# mount /stratis/pool1/filesystem1 /filesystem1/
# cat /filesystem1/testfile 
this is a test file

Use a systemd unit file to automatically unlock a Stratis pool at boot

It is possible to automatically unlock your Stratis pool at boot without manual intervention. However, a file containing the key must be available. Storing the key in a file might be a security concern in some environments.

The systemd unit file shown below provides a simple method to unlock a Stratis pool at boot and mount the filesystem. Feedback on a better/alternative methods is welcome. You can provide suggestions in the comment section at the end of this article.

Start by creating your key file with the following command. Be sure to substitute passphrase with the same key data / passphrase you entered previously.

# echo -n passphrase > /root/pool1key

Make sure that the file is only readable by root:

# chmod 400 /root/pool1key
# chown root:root /root/pool1key

Create a systemd unit file at /etc/systemd/system/stratis-filesystem1.service with the following content:

[Unit]
Description = stratis mount pool1 filesystem1 file system
After = stratisd.service

[Service]
ExecStartPre=sleep 2
ExecStartPre=stratis key set --keyfile-path /root/pool1key pool1key
ExecStartPre=stratis pool unlock
ExecStartPre=sleep 3
ExecStart=mount /stratis/pool1/filesystem1 /filesystem1
RemainAfterExit=yes

[Install]
WantedBy = multi-user.target

Next, enable the service so that it will run at boot:

# systemctl enable stratis-filesystem1.service

Now reboot and verify that the Stratis pool has been automatically unlocked and that its filesystem is mounted.

Summary and conclusion

In today’s environment, encryption is a must for many people and organizations. This post demonstrated how to enable encryption in Stratis 2.1.

FAQs and Guides For System Administrators

17 Comments

  1. A very nice article, I wasn’t aware of stratis at all. But I have one question: how is stratis relationship to LVM, cryptsetup and alike? Is stratis a daemon working on top of these or is it managing an entire own implementation of the storage management? Do they interfere with each other?

    Also, one minor remark: in the key management part during automated unlock, the proper order would be:

    touch /root/pool1key
    chown root:root /root/pool1key
    chmod 400 /root/pool1key
    echo “secret password” > /root/pool1key

    This would eliminate the possible race condition where the previous owner, given that the file already exist and was owned by a non-root user, could modify the permissions of the file before its ownership is changed, resulting in unexpected access to the file for the previous owner.

    Hope that helps and looking forward to the next article!

  2. Oscar

    Why Fedora has choosen btrfs (deprecated by RedHat) instead of Stratis? I can’t understand.

  3. Felipe

    Great post! Shouldn’t all hashtags be a dollar sign?

    • Brian Smith

      Hi Felipe,
      The commands in the article were run as the root user, indicated by the “# ” prompt.

    • Hi Felipe. The hashtags would be dollar signs for unprivileged commands. The commands being demonstrated in this article require super user privileges. The hashtag indicates that super user mode has been locked on by entering “sudo -i” so that every command does not need to be prefixed with sudo individually.

    • Ross

      There are no hashtags in this post. A hashtag is a hash (#) followed by a tag (one or more non-whitespace characters) — ‘#’ alone is just called a hash (or octothorpe, number sign, etc).

  4. T

    If you wrote the password in a file on the hard drive anyway, what’s the point of encryption in the first place? Or am I missing something.

    For a bad guy sitting with the hard drive connected to his system or your laptop booted into single mode in front of him, it’s not rocket science to figure out how it gets mounted at boot time.

    • Brian Smith

      Hi, as I mentioned in the article there are some security concerns with storing the key in a file. It is not required that you store it in file, you can always follow the steps in the “Access the encrypted pool after a reboot” section to manually re-create the key after each reboot.

      Also keep in mind that in the example in this article, the key file is stored in the root filesystem. If the Stratis device was a removable storage drive, if the removable drive was lost/stolen by itself it would not have the key file on it (it would be on the systems root filesystem). So in other words, if you had a USB drive with encrypted Stratis on it, and lost the USB drive and not the laptop (root filesystem), the Stratis USB drive would not have the key file on it.

      Also, your root filesystem could be encrypted (with LUKS). In that case, your laptop and the Stratis USB drive could be stolen, and without the LUKS password they couldn’t get to the Stratis key file in the root filesystem.

    • This depends on the scenario, I think.
      If the storage is local, and you have the passphrase in a file, then the benefit of encryption might indeed come down to “instead of zeroing the device for removing the data, I can remove the passphrase file”.
      If your volumes are backed by iSCSI devices provided by some remote system, then even having the passphrase in the local file can help you: then you “just” have to trust/secure the local system and not the system providing the iSCSI devices.

      • T

        Yours and Brian’s replies are all valid, and highlight how the proposed solution might still be viable in some cases.

        The article as it stands does not reflect this. It still says “in some cases this might be a security concern”.

        Quite the opposite is true at best; “in a few special scnearios this might be a meaningful approach” sounds more right.

        For the likely reader of this article putting the pass phrase in a clear text file on the local hard drive would negate all security benefits that come with encr.yption in the first place.

        If you access centralized storage that needs to be decrypted before accessing, you are likely not the kind of guy who needs to be told that you can put your passphrase in a clear text file on the local hard drive to mount it on boot using systemd.

        Removable storage is a valid case, and reading on how to mount your encrypted usb device seemlessly when you plug it in, would make for a nice read. Though currently you need to dig deep down into the comments to figure that out. And in the same time un-learn the first impression you got from reading the article.

  5. Federico Chiacchiaretta

    What about Clevis TPM integration with Stratis? Is there a roadmap?

  6. Dennis Keefe

    Stratis has been working on this feature. Here are some links to the work.

    Clevis support
    https://github.com/stratis-storage/project/issues/192
    Prototype of clevis integration from CLI
    https://github.com/stratis-storage/stratis-cli/pull/657

  7. Thank you, I have recently been looking for information about this subject for
    a while and yours is the best I have discovered so far.
    But, what about the bottom line? Are you positive about the
    source?

    my website ket bilietai nemokamai

Comments are Closed

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. Fedora Magazine aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. The Fedora logo is a trademark of Red Hat, Inc. Terms and Conditions