Create an fapolicyd track

fapolicyd/background.sh

@@ -0,0 +1,12 @@
+#!/bin/bash
+echo "Adding wheel" > /root/post-run.log
+usermod -aG wheel rhel
+
+echo "Setting password" >> /root/post-run.log
+echo redhat | passwd --stdin rhel
+
+echo "Adding cowsay" >> /root/post-run.log
+curl -L https://github.com/Code-Hex/Neo-cowsay/releases/download/v2.0.4/cowsay_2.0.4_Linux_x86_64.tar.gz | tar xvz -C /home/rhel
+
+echo "Fixing permissions" >> /root/post-run.log
+chown rhel:rhel /home/rhel/*

fapolicyd/finish.md

@@ -0,0 +1,17 @@
+# In this lab you have:
+* Installed the File Access Policy Daemon (fapolicyd)
+* Verified fapolicyd configuration and blocked unauthorized applications
+* Created a file-backed trust database to allow trusted applications
+* Configured SHA-256 hash integrity checking for fapolicyd
+
+# Report an issue with the lab:
+[RHEL Labs Github issues](https://github.com/rhel-labs/learn-katacoda/issues)
+
+
+# Provide additional comments or ratings:
+[Complete a survey about the lab](https://forms.gle/vipkbKFYcKx9YYSs6)
+
+# For more Red Hat labs, check out:
+[Red Hat Enterprise Linux](https://lab.redhat.com)
+
+[OpenShift](https://learn.openshift.com)# Report an issue with the lab:

fapolicyd/index.json

@@ -0,0 +1,36 @@
+{
+  "title": "Application control with fapolicyd",
+  "description": "Goal: After completing this scenario, users will understand how to manage application control with the File Access Policy Daemon (fapolicyd)",
+  "time": "10 minutes",
+  "details": {
+    "steps": [
+      {
+        "title": "Step 1",
+        "text": "step1.md"
+      },
+      {
+        "title": "Step 2",
+        "text": "step2.md"
+      },
+      {
+        "title": "Step 3",
+        "text": "step3.md"
+      }
+    ],
+    "intro": {
+      "text": "intro.md",
+      "credits": "__Author:__ Shane Boulden, Solution Architect (Red Hat)",
+      "courseData": "background.sh"
+    },
+    "finish": {
+      "text": "finish.md"
+    }
+  },
+  "environment": {
+    "uilayout": "terminal",
+    "terminals": [{"name": "fapolicyd", "target":"host01"}]
+  },
+  "backend": {
+    "imageid": "rhel8-5"
+  }
+}

fapolicyd/intro.md

@@ -0,0 +1,13 @@
+# Goal:
+After completing this scenario, users will be able to deploy and manage application control on Red Hat Enterprise Linux 8 systems.
+
+# Concepts included in this scenario:
+* Install the File Access Policy Daemon (fapolicyd)
+* Verify fapolicyd configuration and block unauthorized applications
+* Create a file-based trust database to allow trusted applications
+* Configure integrity checking for fapolicyd
+
+# Example Usecase:
+In this lab, you are going to configure application control for Red Hat Enterprise Linux 8 systems. Application control is a security approach designed to protect against unauthorized process execution on systems. When implemented correctly, application control helps mitigate the risk of malicious code (malware), such as ransomware, executing on a system.
+
+Application control is recognised by the Australian Signals Directorate as one of the most effective mitigation strategies in ensuring the security of systems. It is a recommended strategy included in the Australian Signals Directorate's [Essential Eight](https://www.cyber.gov.au/acsc/view-all-content/publications/implementing-application-control) mitigation strategies, as well as the National Security Agency's (NSA) [Top Ten CyberSecurity Mitigation strategies](https://www.nsa.gov/portals/75/documents/what-we-do/cybersecurity/professional-resources/csi-nsas-top10-cybersecurity-mitigation-strategies.pdf).

fapolicyd/step1.md

@@ -0,0 +1,19 @@
+The File Access Policy Daemon (fapolicyd) controls the execution of applications based on a user-defined policy, and is one of the most effective ways to mitigate the risk of untrusted and possibly malicious applications on the system.
+
+First, install the fapolicyd package on your Red Hat Enterprise Linux system.
+
+`yum install fapolicyd`{{ execute T1 }}
+
+Next, inspect the fapolicyd configuration that has been created.
+
+`cat /etc/fapolicyd/fapolicyd.conf`{{ execute T1 }}
+
+We can see a couple of things have been configured for us by default:
+
+* The daemon is configured in enforcing mode (`permissive = 0`), meaning all unauthorized processed will be blocked. We can optionally configure the daemon for permissive mode and to log unauthorized processes, rather than block them.
+
+* A new user has been created on the system for the daemon (`uid = fapolicyd`)
+
+* The default sources of trust are the RPM database and a file-backed trust database. This means that any packages installed into the RPM database will be trusted by default. In addition, a file is configured at `/etc/fapolicyd/fapolicyd.trust` which can be used for third-party binaries and other applications not installed into the RPM database.
+
+* There is currently no integrity checking configured (`integrity = none`)

fapolicyd/step2.md

@@ -0,0 +1,47 @@
+Now that we've seen how the daemon is configured, let's see it in action.
+
+Switch to the user `rhel`, with the password `redhat`
+
+`su - rhel` {{ execute T1 }}
+
+In the user's home directory is a compiled binary, `cowsay`. There is nothing inherently malicious about this binary, though it provides a good example for our application control workflow. 
+
+You should have no problems executing the `cowsay` binary:
+
+`./cowsay "mooooo"`{{ execute T1 }}
+
+Let's start up fapolicyd and see what happens:
+
+`sudo systemctl start fapolicyd` {{ execute T1 }}
+`./cowsay "mooooo"` {{ execute T1 }}
+
+Great! Because the `cowsay` binary isn't in the RPM database, or the file-backed trust database configured at `/etc/fapolicyd/fapolicyd.trust`, the execution is blocked.
+
+What if we know that this binary is trusted, and we want to allow it on the system? We have a couple of options:
+
+* We could create a RPM spec file for the binary, build an RPM, sign it, and install it into the RPM database
+* We can update the file-backed trust database
+
+The second option seems better for this scenario - let's update the file-backed trust database. We can use the `fapolicyd-cli` to update the trust source:
+
+`sudo fapolicyd-cli --file add /home/user1/cowsay` {{ execute T1 }}
+
+If we take a look at the file `/etc/fapolicyd/fapolicyd.trust` we can see that changes that have been made:
+
+`sudo cat /etc/fapolicyd/fapolicyd.trust` {{ execute T1 }}
+
+* The full-path to the file is listed (`/home/user1/cowsay`)
+* The size of the file has been calculated and added
+* The SHA-256 hash for the file has been calculated and added
+
+Remember that we have `integrity = none` in our fapolicyd config file? These last two attributes - size and the SHA-256 has - are used for integrity checking. We'll take a closer look at this in the next step of the lab.
+
+Now you can update the daemon:
+
+`sudo fapolicyd-cli --update`{{ execute T1 }}
+
+Let's try the binary again:
+
+`./cowsay "mooooo"` {{ execute T1 }}
+
+Success! We've verified that fapolicyd can block unauthorized processes and applications on a system, and that we can manage exceptions for trusted applications.

fapolicyd/step3.md

@@ -0,0 +1,36 @@
+Let's take a quick look at fapolicyd and integrity. The `more` command is installed via the RPM database, so it's trusted to execute on the system:
+
+`sudo rpm -qf /bin/more` {{ execute T1 }}
+
+What if the more command was substituted out for something malicious? First, let's verify that fapolicyd is still running:
+
+`sudo systemctl status fapolicyd`
+
+Now let's substitute the `more` command for the `cowsay` binary in our user's home directory:
+
+`sudo /bin/cp ./cowsay /bin/more` {{ execute T1 }}
+`/bin/more "mooooo" {{ execute T1 }}
+
+Hmmmm. So by default, fapolicyd doesn't check what the file looks like, only where it is executing from. This means that an attacker could potentially hijack the execution path of a trusted file, and execute malicious code on behalf of a user.
+
+To mitigate these scenarios, fapolicyd supports different types of file integrity:
+
+* File-size checking - this is a very fast method of integrity checking, where fapolicyd verifies that the file is the correct size before allowing execution
+* Comparing SHA-256 hashes - computing and checking SHA-256 checksums is more secure than file-size checking, but does have an impact on system performance.
+* Integrity Measurement Architecture (IMA) subsystem - IMA can be used by fapolicyd to support file integrity checks.
+
+For this scenario we're going to use SHA-256 hashes to verify file integrity. This provides a good balance between speed and security, and is simple to setup and maintain.
+
+You can configure integrity in the `/etc/fapolicyd/fapolicyd.conf` file:
+
+`sudo sed -i 's/integrity.*/integrity = sha256/' /etc/fapolicyd/fapolicyd.conf` {{ execute T1 }}
+
+Restart the daemon:
+
+`sudo systemctl restart fapolicyd` {{ execute T1 }}
+
+We can now verify whether file integrity checking is performed:
+
+`/bin/more "mooooooo"` {{ execute T1 }}
+
+Success! We've now mitigated the risk of an attacker hijacking a trusted binary on the system, by configuring fapolicyd integrity controls.