Policy-Based Decryption (Lesson 6 transcript from Upgrading to Red Hat Enterprise Linux (RHEL) 8 LiveLessons)

Lesson 6 Introduction

Hi, welcome to lesson six. In this lesson you'll learn how to work with LUKS encryption. While LUKS encryption itself is not new, the option to enable access to LUKS encrypted devices by authorizing to a network server is new. In this lesson, you'll learn how to work with it.

Setting up LUKS

So, this lesson is about policy-based decryption. Policy-based decryption is used for LUKS. LUKS are encrypted devices. An inconvenience is that in order to use a LUKS-encrypted device, you need to enter a passphrase. And that's why we want to use policy-based decryption. But before you can do that, you need to set up a LUKS device. On the slide I have summarized a procedure and I'm going to demonstrate how to apply this procedure. So, before we can create an encrypted device we need a block device.

So let me start at lsblk to list current block devices. And we can see that there's a disc nvme0n2. I'm going to use that c encrypted device. In order to do so, I'm using cryptsetup luksformat on dev nvme0n2. We can see that this device has been used for something else previously. I don't care, I'm going to override it. So I say, yes.

Next it is asking for a passphrase. This passphrase needs to be reasonable complex and it needs to be used while accessing the encrypted device. At this point I have created the cryptographic layer on top of the LUKS device. So let's first verify that we can open it. In order to do so I'm using cryptsetup luksOpen followed by the name of the device. Followed by the name of an encrypted device that needs to be created. So the secret in here is a new device that will be created, after I have entered the passphrase. And that is exactly what is wrong with this procedure. Encrypted devices are very nice, but if you use them on the server, you don't want manual interaction to enter a passphrase, but for now we don't have any choice. So by using the cryptsetup luksOpen, I have opened the encrypted device. And we should see the results in the dev mapper directory. What I'm looking for is this. Here we can see the secret device that has been created in dev/mapper and that's the opened encrypted device. In order to do something with it I need to put a file system on top. So mkfs.xfs on dev mapper secret will do that for me. And now I must make sure that I can mount it, so let me create the directory and next use mount of dev mapper secret on /secret. And at this point it is working. If I want to automate this and automatically start the encrypted device while booting then I need to create the file etc crypttab. So in etc/crypttab I need to specify the name of the file that needs to be created. That will be secret. Then I need to specify the name of the underlying device, that is nvme0n2.

Next I'm using none. The none indicates that I don't want to feed a passphrase through this configuration file and I need _netdev. _netdev is a mandatory option if you want to automate this procedure later on. So this part will make sure that the encrypted device is opened while booting, but it doesn't mount it. In order to mount it, I also need to edit etc fstab. So what are we going to do in etc fstab, well we are going to use dev mapper secret which is the name of the opened encrypted device we mounted on /secret. We set the file system to xsf and we need the mount option netdev and then we include 00 which is quite common as mount options. That should do it so at this point if I reboot the encrypted device should be initialized. Let's have a look. So this is what happens. You can see that I am prompted to enter the passphrase at this point. And even if that works, that isn't convenient at all and that is why we have policy-based decryption, which we will talk about next.