From 525ca0001ffeaf3f58a5a25c5b322cf61de0ec66 Mon Sep 17 00:00:00 2001 From: shaneboulden Date: Mon, 9 May 2022 15:59:25 +1000 Subject: [PATCH 1/5] added fapolicyd track --- fapolicyd/finish.md | 17 +++++++++++++++++ fapolicyd/index.json | 33 +++++++++++++++++++++++++++++++++ fapolicyd/intro.md | 13 +++++++++++++ fapolicyd/step1.md | 23 +++++++++++++++++++++++ fapolicyd/step2.md | 33 +++++++++++++++++++++++++++++++++ fapolicyd/step3.md | 36 ++++++++++++++++++++++++++++++++++++ 6 files changed, 155 insertions(+) create mode 100644 fapolicyd/finish.md create mode 100644 fapolicyd/index.json create mode 100644 fapolicyd/intro.md create mode 100644 fapolicyd/step1.md create mode 100644 fapolicyd/step2.md create mode 100644 fapolicyd/step3.md diff --git a/fapolicyd/finish.md b/fapolicyd/finish.md new file mode 100644 index 00000000..b3884bf1 --- /dev/null +++ b/fapolicyd/finish.md @@ -0,0 +1,17 @@ +# In this lab you have: +* Installed the File Access Policy Daemon (fapolicyd) +* Verified fapolicyd configuration +* Created a file-based trust database to list known-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: diff --git a/fapolicyd/index.json b/fapolicyd/index.json new file mode 100644 index 00000000..b5fac7e5 --- /dev/null +++ b/fapolicyd/index.json @@ -0,0 +1,33 @@ +{ + "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)", + "details": { + "steps": [ + { + "title": "Step 1", + "text": "step1.md" + }, + { + "title": "Step 2", + "text": "step2.md" + }, + { + "title": "Step 3", + "text": "step3.md" + } + ], + "intro": { + "text": "intro.md" + }, + "finish": { + "text": "finish.md" + } + }, + "environment": { + "uilayout": "terminal", + "terminals": [{"name": "fapolicyd", "target":"host01"}] + }, + "backend": { + "imageid": "rhel8-5" + } +} diff --git a/fapolicyd/intro.md b/fapolicyd/intro.md new file mode 100644 index 00000000..b8cc400e --- /dev/null +++ b/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 +* Create a file-based trust database +* 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. + +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]. diff --git a/fapolicyd/step1.md b/fapolicyd/step1.md new file mode 100644 index 00000000..4deba002 --- /dev/null +++ b/fapolicyd/step1.md @@ -0,0 +1,23 @@ +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 not configured for permissive mode (`permissive = 0`), meaning all unauthorized processed will be blocked. We can optionally configure the daemon for permissive mode and to log unauthorized processes. + +* 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`) + +We don't need to make any changes to this configuration for now, and you can start up the daemon: + +`systemctl start fapolicyd`{{ execute T1 }} diff --git a/fapolicyd/step2.md b/fapolicyd/step2.md new file mode 100644 index 00000000..ae2da635 --- /dev/null +++ b/fapolicyd/step2.md @@ -0,0 +1,33 @@ +Now that we've seen how the daemon is configured, let's see it in action. + +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` + +Great! Because the `cowsay` binary isn't in the RPM database, or the fapolicyd 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, and install it into the RPM database +* We can update the fapolicyd trust database + +The second option seems better for this scenario - let's update the fapolicyd trust database. We can use the `fapolicyd-cli` to update file-backed trust source: + +`sudo fapolicyd-cli --file add /home/user1/cowsay` {{ execute T1 }} + +Now you can update the daemon: + +`sudo fapolicyd-cli --update`{{ execute T1 }} + +Now 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. diff --git a/fapolicyd/step3.md b/fapolicyd/step3.md new file mode 100644 index 00000000..2c306888 --- /dev/null +++ b/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: + +`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: + +`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. From 6a3125c4cac5e2e76b4786baaf231b51e7653396 Mon Sep 17 00:00:00 2001 From: shaneboulden Date: Tue, 10 May 2022 08:43:32 +1000 Subject: [PATCH 2/5] added a setup script --- fapolicyd/background.sh | 9 +++++++++ fapolicyd/index.json | 5 ++++- 2 files changed, 13 insertions(+), 1 deletion(-) create mode 100644 fapolicyd/background.sh diff --git a/fapolicyd/background.sh b/fapolicyd/background.sh new file mode 100644 index 00000000..ff1488a8 --- /dev/null +++ b/fapolicyd/background.sh @@ -0,0 +1,9 @@ +#!/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 diff --git a/fapolicyd/index.json b/fapolicyd/index.json index b5fac7e5..734e592b 100644 --- a/fapolicyd/index.json +++ b/fapolicyd/index.json @@ -1,6 +1,7 @@ { "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": [ { @@ -17,7 +18,9 @@ } ], "intro": { - "text": "intro.md" + "text": "intro.md", + "credits": "__Author:__ Shane Boulden, Solution Architect (Red Hat)", + "courseData": "background.sh" }, "finish": { "text": "finish.md" From 007e8a64b4957b4ca08f20866c2d156f633c05ae Mon Sep 17 00:00:00 2001 From: shaneboulden Date: Tue, 10 May 2022 08:44:43 +1000 Subject: [PATCH 3/5] updated links and concepts --- fapolicyd/finish.md | 4 ++-- fapolicyd/intro.md | 8 ++++---- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/fapolicyd/finish.md b/fapolicyd/finish.md index b3884bf1..6bdc300f 100644 --- a/fapolicyd/finish.md +++ b/fapolicyd/finish.md @@ -1,7 +1,7 @@ # In this lab you have: * Installed the File Access Policy Daemon (fapolicyd) -* Verified fapolicyd configuration -* Created a file-based trust database to list known-trusted applications +* 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: diff --git a/fapolicyd/intro.md b/fapolicyd/intro.md index b8cc400e..01678b57 100644 --- a/fapolicyd/intro.md +++ b/fapolicyd/intro.md @@ -3,11 +3,11 @@ After completing this scenario, users will be able to deploy and manage applicat # Concepts included in this scenario: * Install the File Access Policy Daemon (fapolicyd) -* Verify fapolicyd configuration -* Create a file-based trust database +* 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. +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]. +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). From 4bc3b782380a3f87a641a085064b10a0e3644db8 Mon Sep 17 00:00:00 2001 From: shaneboulden Date: Tue, 10 May 2022 08:45:12 +1000 Subject: [PATCH 4/5] created a non-privileged user --- fapolicyd/step1.md | 6 +----- fapolicyd/step2.md | 28 +++++++++++++++++++++------- fapolicyd/step3.md | 4 ++-- 3 files changed, 24 insertions(+), 14 deletions(-) diff --git a/fapolicyd/step1.md b/fapolicyd/step1.md index 4deba002..42f25b39 100644 --- a/fapolicyd/step1.md +++ b/fapolicyd/step1.md @@ -10,14 +10,10 @@ Next, inspect the fapolicyd configuration that has been created. We can see a couple of things have been configured for us by default: -* The daemon is not configured for permissive mode (`permissive = 0`), meaning all unauthorized processed will be blocked. We can optionally configure the daemon for permissive mode and to log unauthorized processes. +* 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`) - -We don't need to make any changes to this configuration for now, and you can start up the daemon: - -`systemctl start fapolicyd`{{ execute T1 }} diff --git a/fapolicyd/step2.md b/fapolicyd/step2.md index ae2da635..34699cb8 100644 --- a/fapolicyd/step2.md +++ b/fapolicyd/step2.md @@ -1,5 +1,9 @@ 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: @@ -8,25 +12,35 @@ You should have no problems executing the `cowsay` binary: Let's start up fapolicyd and see what happens: -`sudo systemctl start fapolicyd`{{ execute T1 }} -`./cowsay` +`sudo systemctl start fapolicyd` {{ execute T1 }} +`./cowsay "mooooo"` {{ execute T1 }} -Great! Because the `cowsay` binary isn't in the RPM database, or the fapolicyd trust database configured at `/etc/fapolicyd/fapolicyd.trust`, the execution is blocked. +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, and install it into the RPM database -* We can update the fapolicyd trust database +* 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 fapolicyd trust database. We can use the `fapolicyd-cli` to update file-backed trust source: +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 }} -Now let's try the binary again: +Let's try the binary again: `./cowsay "mooooo"` {{ execute T1 }} diff --git a/fapolicyd/step3.md b/fapolicyd/step3.md index 2c306888..dca68883 100644 --- a/fapolicyd/step3.md +++ b/fapolicyd/step3.md @@ -1,10 +1,10 @@ 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: -`rpm -qf /bin/more` {{ execute T1 }} +`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: -`systemctl status fapolicyd` +`sudo systemctl status fapolicyd` Now let's substitute the `more` command for the `cowsay` binary in our user's home directory: From 56e2a5708666a0f62d27237f3f6f18b704b34480 Mon Sep 17 00:00:00 2001 From: shaneboulden Date: Tue, 10 May 2022 09:23:53 +1000 Subject: [PATCH 5/5] fixed permission for lab user --- fapolicyd/background.sh | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/fapolicyd/background.sh b/fapolicyd/background.sh index ff1488a8..11736b2f 100644 --- a/fapolicyd/background.sh +++ b/fapolicyd/background.sh @@ -6,4 +6,7 @@ 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 +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/*