Lab 5.0 - SELinux container integration

Start by running a container that mounts /sys/fs/selinux as read-only then runs a command (id -Z) that requires an SELinux enabled kernel. This is called bind mounting and is done with the -v option. Once the command runs, the container terminates.

As noted above, our workaround to make the container aware that SELinux is running on the host is to mount the /sys/fs/selinux directory as read/write and touch the SELinux configuration file.

Give this a try and confirm the expected SELinux label is reported. You will need to run the container as root with the --privileged flag:

Enter the container and try an SELinux command. it should fail because both conditions have not been met:

Now touch the config file and try again. It should succeed. Note the SELinux label that is returned and the file label:

Exit the container:

As you learned above, bind mounts allow a container to mount a directory on the host for general application usage. This lab will help you understand how selinux behaves in different bind mounting scenarios.

On the bastion, let’s create a directory named /data. Make note of the file permissions. Could a container read or write to this directory?

Open the permissions on /data to all users:

Run bash in a container and volume mount the /data directory on host to the /data directory in the container’s file system:

Notice that the shell prompt changes to [root@33659a200e02 /]# when you enter the container namespace.

Did the mount succeed? How can you check?

Run the df command to verify the volume is mounted to the /data directory.

Try to list the contents of /data:

Try to create a file in the /data directory? The command will also fail. Why? Hint: Is SELinux is involved? How would you investigate?

The sealert tool will analyze and decode the audit.log file and make suggestions on how to remedy the problem.

To investigate, run the sealert tool on the bastion system:

There sealert tool produces a lot of information here. It should report that SELinux is preventing /usr/bin/bash from writing to the /data directory. It should also report that to allow bash to have write access to /data, the SELinux label must be changed on that directory.

From the container host, examine the SELinux label of /data and note the type is default_t. From the discussion at the beginning of this lab, you know this is an SELinux label mismatch.

Based on the default SELinux policy for containers, The label of the process does not match the label of the target directory.

Take sealerts’s suggestion of changing the label type of the /data directory to container_file_t:

Confirm that /data is now correctly labeled:

To allow this container to write to the /data , we also need to change the owner of the directory to ec2-user on the client. Why is this?

Check the permissions and labels again:

Now run the container again and try to write into /data as you did above. Did the write succeed?

Notice the directory permissions in the container. The owner is root (user namespaces in action):

Time to exit the container namespace:

Finally, check the directory on the host. You should see the file that was created with the correct ownership

Now you’ll let podman create the SELinux labels. To change a label in the container context, you can add either of two suffixes :z or :Z to the volume mount. These suffixes tell podman to relabel file objects on the shared volumes. The :Z option tells podman to label the content with a private unshared label.

Repeat the scenario above but instead add the :Z option to bind mount the /private directory then try to create a file in the /private directory from the container’s namespace.

First examine the default label for any new directory:

Now run a container in the background that bind mounts /private using the :Z option:

Examine the label again:

Note the addition of a unique Multi-Category Security (MCS) label (c422,c428) to the directory. SELinux takes advantage of MCS separation to ensure that the processes running in the container can only write to files with the same MCS Label.

Stop and remove the container:

Repeat the scenario above but instead add the :z option for the bind mount then try to create a file in the /shared directory from the container’s namespace. The :z option tells podman that two containers share the volume content. As a result, podman labels the content with a shared content label. Shared volume labels allow all containers to read/write content.

Create a directory named /shared and examine the label:

Now run a container that bind mounts /shared using :z, and then create a file in /shared:

On the host, notice the correct SELinux label on the shared directory:

Repeat with a second container. It should succeed.

On the host, confirm the shared directory contains the files created by the containers.

Imagine a scenario where an application gets compromised. The first thing the bad guy wants to do is to write an exploit into the container, so the next time the application starts up, it starts up with the exploit in place. If the container was read-only it would prevent leaving a backdoor in place and be forced to start the cycle from the beginning.

Container engines added a read-only feature but it presents challenges since many applications need to write to temporary directories like /run or /tmp and when these directories are read-only, the apps fail. Red Hat’s approach leverages tmpfs. It’s a nice solution to this problem because it eliminates data exposure on the host. As a recommended practice, run all applications in production in this mode and only allow write operations to known directories.

To experiment with this feature, run a read-only container and specify a few writable file systems using the --tmpfs option:

Now, try the following. What fails and what succeeds? Why?

We’ve covered a lot of ground here on Dan’s favorite topic. You should feel good.

×

Workshop Details

Domain
Workshop
Student ID

Student ID 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200

Domain rhnaps.io redhatgov.io az.redhatgov.io redhat-fierce.io fiercesw.network rhtps.io openshiftworkshop.com redhatpsmwsa.com open.redhat.com opentlc.com aroapp.io danclark.io

Workshop

Enter Default

Workshop Details

Domain
Workshop
Student ID