From 04f9f0a24ddb4766a8b6813c8a2b36f329ce1b38 Mon Sep 17 00:00:00 2001
From: ael1lud <andreas.elvstam@se.bosch.com>
Date: Mon, 29 Mar 2021 18:11:47 +0200
Subject: [PATCH] Restructure existing guide to merge with the new one

Update and re-shuffle the existing parts of the apparmor.md guide
to merge the old guide with the new guide:
 - Update summary with new ref links.
 - Reused a few sections but rephrased and updated references.
 - Removed a few, no longer needed, sections.
 - Fix minor formatting

Signed-off-by: Andreas Elvstam Cantner <andreas.elvstam@se.bosch.com>
---
 content/guides/apparmor.md | 280 +++++++++++++++++--------------------
 1 file changed, 130 insertions(+), 150 deletions(-)

diff --git a/content/guides/apparmor.md b/content/guides/apparmor.md
index 22c730e6f..f39e00615 100644
--- a/content/guides/apparmor.md
+++ b/content/guides/apparmor.md
@@ -31,94 +31,31 @@ access to resources on the system.
 
 # Summary
 
-- [Write AppArmor profiles]( {{< ref "#generating-profiles" >}} ) to be as
-  constrained as possible.
-- [Validate the profiles]( {{< ref "#validation" >}} ) manually before release,
-  and during testing.
-
-# AppArmor Profiles
-
-Apparmor profiles are stored in `/etc/apparmor.d` and are named after the full
-path of the executable they confine, with `/` replaced by `.`.
-
-For example, the gpsd executable can be found at `/usr/sbin/gpsd`. This
-executable has the apparmor profile `/etc/apparmor.d/usr.sbin.gpsd`.
-
-# Generating Profiles
+- [AppArmor Profiles]( {{< ref "#apparmor-profiles" >}} )
+    - [Profile Introduction]( {{< ref "#profile-introduction" >}} )
+        - [Profile Modes]( {{< ref "#profile-modes" >}} )
+        - [System Logs]( {{< ref "#system-logs" >}} )
+    - [Profile Development]( {{< ref "#profile-development" >}} )
+        - [Development Environment]( {{< ref "#development-environment" >}} )
+        - [Manually Write the Profile]( {{< ref "#manually-write-the-profile" >}} )
+        - [Tool Aided Profile Development]( {{< ref "#tool-aided-profile-development" >}} )
+        - [Developing Common Parts For Multiple Profiles]( {{< ref "#developing-common-parts-for-multiple-profiles" >}} )
+    - [Profile Validation]( {{< ref "#profile-validation" >}} )
+    - [Installing Profiles]( {{< ref "#installing-profiles" >}} )
+    - [Profile Syntax and Examples]( {{< ref "#profile-syntax-and-examples" >}} )
+        - [File Access]( {{< ref "#file-access" >}} )
+        - [Resource Limit Control]( {{< ref "#resource-limit-control" >}} )
+        - [Capabilities]( {{< ref "#capabilities" >}} )
+            - [Capabilities Introduction]( {{< ref "#capabilities-introduction" >}} )
+            - [Capabilities and AppArmor]( {{< ref "#capabilities-and-apparmor" >}} )
+        - [Mount]( {{< ref "#mount" >}} )
+    - [Best Practices]( {{< ref "#best-practices" >}} )
 
+# Apparmor Profiles
 For application development, the only work which needs to be done for AppArmor
 integration is to write and install a profile for the application.
-
-## Development Environment
-
-The OSTree images do not offer a very friendly environment for development, it is best to perform such development using the [apt based images]({{< ref "images.md" >}}). To use the tools mentioned below, the `apparmor-utils` package will need to be installed:
-
-    sudo apt install apparmor-utils
-
-## Creating Profiles
-
-If starting from scratch, you can use `aa-genprof` to create a basic profile.
-This will then need to be worked to describe the functionality needed by the
-executable.  Profiles should be as constrained as possible, following the
+Profiles should be as constrained as possible, following the
 [principle of least privilege](http://en.wikipedia.org/wiki/Principle_of_least_privilege).
-See the
-[AppArmor website](https://gitlab.com/apparmor/apparmor/-/wikis/Profiles) for
-information on writing profiles.
-
-The profiles can be loaded with the following command:
-
-    sudo apparmor_parser -r < /etc/apparmor.d/my.new.profile
-
-Typically this is performed with the profile in `complain` rather than
-`enforce` mode. The status of the profiles can be determined by running `sudo
-aa-status`.
-
-# Validation
-
-AppArmor profiles can be validated in two ways: at runtime and manually.
-
-Runtime verification is automatic: AppArmor will deny access to files which
-violate the profile, emitting a message in the audit logs (`audit.log`), for
-example:
-
-    Feb 23 18:54:07 my-host kernel: [   24.610703] type=1400 audit(1393181647.872:15): apparmor="DENIED" operation="open" parent=1 profile="/usr/sbin/ntpd" name="/etc/ldap/ldap.conf" pid=1526 comm="ntpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
-
-These can be found with the following commands:
-
-    sudo grep DENIED /var/log/audit/audit.log
-    sudo journalctl -b | grep DENIED
-
-Such messages should be investigated, and may result in changes to the
-application (to prevent it making such accesses) or to the profile (to allow
-them). The
-[AppArmor documentation](https://gitlab.com/apparmor/apparmor/-/wikis/QuickProfileLanguage)
-covers the
-[syntax in more detail](https://gitlab.com/apparmor/apparmor/-/wikis/AppArmor_Core_Policy_Reference).
-
-Manual verification should be performed before each release, manually
-inspecting the profile against the list of changes made to the application
-since the last release, and checking that each entry is still relevant and
-correct, and that no new entries are needed.
-
-Manual and runtime verification are complementary: manual verification ensures
-the profile is as small as possible; runtime verification ensures the profile
-is as big as it needs to be.
-
-## Installing Profiles
-
-Once the profile is working as required add it to the relevant package
-(typically in the `debian/apparmor.d` directory) and
-[submit it for review]({{< ref "upstreaming.md" >}}),
-
-
-# External links
-
-- [AppArmor home page](http://wiki.apparmor.net/index.php/Main_Page)
-- [AppArmor profile wiki page](http://wiki.apparmor.net/index.php/Profiles)
-
-
-
-# Apparmor Profiles
 
 ## Profile Introduction
 Since the AppArmor profile that confines an executable is what determines
@@ -126,9 +63,9 @@ what the executable is allowed to do, profile development is a key part of the
 development cycle when using AppArmor. Generally speaking there are two ways to
 develop AppArmor profiles, either manually write the profiles or use a tool to generate
 them. Regardless of which method is preferred when developing the profiles the
-utility tools found in the package "apparmor-utils" are essential during the
+utility tools found in the package `apparmor-utils` are essential during the
 development phase of AppArmor profiles. It is therefore suggested to install the
-apparmor-utils package, for example by:
+`apparmor-utils` package, for example by:
 
     sudo apt install apparmor-utils
 
@@ -144,8 +81,8 @@ of new profiles or making updates of the existing ones.
 
 {{% notice note %}}
 Profiles in complain mode do not in any way impact what is blocked by the
-[Discretionary Access Control](https://en.wikipedia.org/wiki/Discretionary_access_control)
-(DAC) on the system, as the DAC rules are evaluated before the MAC rules.
+[Discretionary Access Control (DAC)](https://en.wikipedia.org/wiki/Discretionary_access_control)
+ on the system, as the DAC rules are evaluated before the MAC rules.
 {{% /notice %}}
 
 Setting an existing profile in complain mode can be done in two ways:
@@ -166,14 +103,14 @@ Note that the directories above may differ depending on the logging configuratio
 on the system. These logs can be examined to
 identify what the executable is doing on the system, that's not explicitly
 allowed by the AppArmor profile. These logs are also used by
-some of the apparmor-utils tools to help develop profiles based on the generated
+some of the `apparmor-utils` tools to help develop profiles based on the generated
 violation logs.
 
 {{% notice tip %}}
 When [journald](https://man7.org/linux/man-pages/man8/systemd-journald.service.8.html)
 is used for system logging, as it should by
 [default on Apertis](https://www.apertis.org/concepts/debug-and-logging/#systemd-journal),
-on a system [journalctl](https://manpages.debian.org/stretch/systemd/journalctl.1.en.html)
+ [journalctl](https://manpages.debian.org/stretch/systemd/journalctl.1.en.html)
 can be used to read the journald log entries.
 {{% /notice %}}
 
@@ -183,27 +120,32 @@ can be used to read the journald log entries.
    from the script "/home/user/write.sh" whose profile was in complain mode. This
    write operation would otherwise have been blocked by AppArmor in case the
    profile had been in enforce mode:
-   ```
-   type=AVC msg=audit(1612792741.460:115061): apparmor="ALLOWED" operation="file_perm" profile="/home/user/write.sh" name="/foo.txt" pid=26376 comm="write.sh" requested_mask="w" denied_mask="w" fsuid=459221780 ouid=459221780
-   ```
+
+        type=AVC msg=audit(1612792741.460:115061): apparmor="ALLOWED" operation="file_perm" profile="/home/user/write.sh" name="/foo.txt" pid=26376 comm="write.sh" requested_mask="w" denied_mask="w" fsuid=459221780 ouid=459221780
+
 
  - Log entry where AppArmor has explicitly created an audit entry for read access
    to the file "/foo.txt". This is due to an audit rule in the profile which is
    confining the executable "/home/user/cat.sh".
-   ```
-   type=AVC msg=audit(1613116865.459:120399): apparmor="AUDIT" operation="open" profile="/home/user/cat.sh" name="/foo.txt" pid=21253 comm="cat" requested_mask="r" fsuid=459221780 ouid=459221780
-   ```
+
+       type=AVC msg=audit(1613116865.459:120399): apparmor="AUDIT" operation="open" profile="/home/user/cat.sh" name="/foo.txt" pid=21253 comm="cat" requested_mask="r" fsuid=459221780 ouid=459221780
+
 
  - Log entry where AppArmor has denied read access to the file "/foo.txt" for the
    script "/home/user/cat.sh". This is either due to an explicit "deny" rule in
    the profile or (more likely) by an implicit deny, due to not explicitly
    whitelisting the read access in the profile.
-   ```
-   type=AVC msg=audit(1613117305.314:121263): apparmor="DENIED" operation="open" profile="/home/user/cat.sh" name="/foo.txt" pid=23035 comm="cat" requested_mask="r" denied_mask="r" fsuid=459221780  ouid=459221780
-   ```
+
+       type=AVC msg=audit(1613117305.314:121263): apparmor="DENIED" operation="open" profile="/home/user/cat.sh" name="/foo.txt" pid=23035 comm="cat" requested_mask="r" denied_mask="r" fsuid=459221780  ouid=459221780
+
 
 ## Profile Development
 
+### Development Environment
+The OSTree images do not offer a very friendly environment for development, it is best to perform such development using the [apt based images]({{< ref "images.md" >}}). To use the AppArmor tools mentioned below, the `apparmor-utils` package will need to be installed:
+
+    sudo apt install apparmor-utils
+
 ### Manually Write The Profile
 AppArmor profiles are located in the directory `/etc/apparmor.d/` and are named
 according to the executable which they are associated with, where slashes (‘/’)
@@ -277,11 +219,11 @@ the executable and generating logs.
 
 ### Tool Aided Profile Development
 To simplify the creation of AppArmor profiles, for e.g. large binaries or
-binaries which require more privileges, the tools inside apparmor-utils can be
+binaries which require more privileges, the tools inside `apparmor-utils` can be
 used. The main tool to use for this is called `aa-genprof` which essentially
 creates an empty profile in complain mode and then scans the system logs for
 any violations associated with the binary for which it is being run. To use
-aa-genprof the following step should be taken:
+`aa-genprof` the following step should be taken:
 
 {{% notice warning %}}
 Make sure the executable runs as it should under the
@@ -297,12 +239,12 @@ then this must also first be considered.
 
  1. Open two terminals.
 
- 2. In terminal 1, start aa-genprof using:
+ 2. In terminal 1, start `aa-genprof` using:
 
          sudo aa-genprof <path/to/executable>
 {{% notice tip %}}
 If `journald` is used as the system logging mechanism then the `journald` logs needs
-to be converted into something the apparmor-utils tools can read. The easiest way
+to be converted into something the `apparmor-utils` tools can read. The easiest way
 is to use [journalctl](https://manpages.debian.org/stretch/systemd/journalctl.1.en.html).
 
 **Example:**
@@ -315,7 +257,7 @@ is to use [journalctl](https://manpages.debian.org/stretch/systemd/journalctl.1.
  3. In terminal 2, run the executable and interact with it to exercise as
     much of its functionality as possible.
 
- 4. In terminal 1, press `s` to have aa-genprof scan the system log for entries
+ 4. In terminal 1, press `s` to have `aa-genprof` scan the system log for entries
     generated by the executable.
 
 {{% notice note %}}
@@ -327,14 +269,14 @@ scanning the log file:
     journactl | grep apparmor >> </path/to/log.txt>
 {{% /notice %}}
 
- 5. Answer the question asked by aa-genprof regarding the found system events.
+ 5. Answer the question asked by `aa-genprof` regarding the found system events.
 
    {{% notice tip %}}
    While performing this step it is preferred to really take a few
    extra seconds to read and understand the proposed rule and the implication
-   of what aa-genprof presents. E.g. if an executable has read 100 files, all
+   of what `aa-genprof` presents. E.g. if an executable has read 100 files, all
    located in the same directory and with the same file extension the tool
-   will suggest to add one rule per such read access, i.e aa-genprof will ask
+   will suggest to add one rule per such read access, i.e `aa-genprof` will ask
    a similar question 100 times. However, a developer that knows this behavior
    of the executable can easily make this process faster by realizing that a
    globbing pattern for these files in this directory can be added as 1 rule,
@@ -355,7 +297,7 @@ scanning the log file:
     all of the different actions performed by the binary has generated system
     log entries.
 
- 7. In terminal 1, press `f` to indicate that aa-genprof shall finish and save
+ 7. In terminal 1, press `f` to indicate that `aa-genprof` shall finish and save
     the profile.
 
  8. Verify that the profile works in enforce mode.
@@ -436,16 +378,52 @@ Example profile for `/path/to/executable3` in the file `/etc/apparmor.d/path.to.
 }
 ```
 
-In the example above, both executable1 and executable2 will have the same base
+In the example above, both `executable1` and `executable2` will have the same base
 set of rules, allowing read access to various files along with execute permission
-for `/bin/cat`. In addition, executable1 will also be able to execute `/bin/echo`
+for `/bin/cat`. In addition, `executable1` will also be able to execute `/bin/echo`
 under the same confinement as itself and AppArmor will allow and audit all read
-and write accesses to the log file `/home/<user>/log/log.txt`. However, executable3
+and write accesses to the log file `/home/<user>/log/log.txt`. However, `executable3`
 will only have a sub-set of the rules in the common file since a deny rule is added
 to override one of the rules from the common file to deny read access to any `.h`
 file in `/usr/include/`.
 
-## File access
+## Profile Validation
+
+AppArmor profiles can be validated in two ways: at runtime and manually.
+
+**Runtime verification** is automatic: AppArmor will deny access to files or resources which
+violate the profile rules, emitting a message in the system logs. See [System Logs]( {{< ref "#system-logs" >}} )
+for details. Such messages should be investigated, and may result in either:
+- Changes to the application (to prevent it making such accesses), or
+- Changes to the profile (to allow such accesses).
+
+**Manual verification** should be performed before each release:
+ 1. Manually inspect the profile against the list of changes made to the application since the last release.
+ 2. Check that each entry is still relevant and correct.
+ 3. Check that no new entries are needed.
+
+Manual and runtime verification are complementary: manual verification ensures
+the profile is as small as possible; runtime verification ensures the profile
+is as big as it needs to be.
+
+## Installing Profiles
+
+Once the profile is working as required add it to the relevant package
+(typically in the `debian/apparmor.d` directory) and
+[submit it for review]({{< ref "upstreaming.md" >}}).
+
+The profiles can be loaded with the following command:
+
+    sudo apparmor_parser -r -v < /etc/apparmor.d/my.new.profile
+
+Typically this is performed with the profile in **complain** rather than
+**enforce** mode. The status of the profiles can be determined by running:
+
+    sudo aa-status
+
+## Profile Syntax and Examples
+
+### File Access
 
 Since the AppArmor security model is a MAC implementation, it can only confine access to resources that the executable’s owner already has access to, according to the DAC access permission rules.
 
@@ -463,11 +441,11 @@ AppArmor can only create permission rules to the files in the green DAC box, and
 | file_4.txt | No      | No      |
 
 
-Based on the above example of DAC and MAC access permissions, the following bash script reads two files that the script’s owner has access to and nothing else. Note that the script does not need to write anything to the files, even though the user could do that. 
+Based on the above example of DAC and MAC access permissions, a simple bash script called `file_access.sh` has been written. The script reads two files that the script’s owner has access to and nothing else. Note that the script does not need to write anything to the files, even though the user could do that.
 
-In order to achieve the desired behavior an AppArmor profile for the executable needs to be created using the `aa-genprof` tool. Before running the `aa-genprof` tool, make sure the file_access.sh script has execute permission for the owner.
+In order to achieve the desired behavior an AppArmor profile for the executable needs to be created using the `aa-genprof` tool. Before running the `aa-genprof` tool, make sure the `file_access.sh` script has execute permission for the owner.
 
-Below is the content of the directory with four text files and the bash script. There is also content of the bash script / executable (file_access.sh) and the created profile (home.user.file_access.sh).
+Below is the content of the directory with four text files and the bash script. There is also content of the bash script / executable `file_access.sh` and the created profile `home.user.file_access.sh`.
 
 Listed files in the `/home/user` directory:
     
@@ -479,27 +457,29 @@ Listed files in the `/home/user` directory:
     -rwxr--r-- user grp … file_access.sh
 
 Below is the content of `file_access.sh`:
+```
+#!/bin/bash
 
-    #!/bin/bash
-    
-    cat file_2.txt
-    cat file_3.txt
+cat file_2.txt
+cat file_3.txt
+```
 
 Below is the content of `/etc/apparmor.d/home.user.file_access.sh`:
-    
-    #include <tunables/global>
-    
-    /home/user/file_access.sh {
-        #include <abstractions/base>
-        #include <abstractions/bash>
-        #include <abstractions/consoles>
- 
-        /home/user/files_access.sh r,
-        /usr/bin/bash ix,
-        /usr/bin/cat mrix,
-        owner /home/*/file_2.txt r,
-        owner /home/*/file_3.txt r,
-    }
+```
+#include <tunables/global>
+
+/home/user/file_access.sh {
+    #include <abstractions/base>
+    #include <abstractions/bash>
+    #include <abstractions/consoles>
+
+    /home/user/files_access.sh r,
+    /usr/bin/bash ix,
+    /usr/bin/cat mrix,
+    owner /home/*/file_2.txt r,
+    owner /home/*/file_3.txt r,
+}
+```
 
 Description of the above profile:
 
@@ -516,21 +496,22 @@ When the `file_access.sh` script is run by "user", it will show the content of t
 Now we change the `file_access.sh` to include reading of two additional files, the one that the user has access to (file_1.txt) and the one that the user doesn’t have access to (file_4.txt), according to the DAC permission rules. After the change, the executable should look like this:
 
 Below is the content of updated `file_access.sh`:
+```
+#!/bin/bash
 
-    #!/bin/bash
-    
-    cat file_1.txt
-    cat file_2.txt
-    cat file_3.txt
-    cat file_4.txt
+cat file_1.txt
+cat file_2.txt
+cat file_3.txt
+cat file_4.txt
+```
 
 When the updated script above is run again, AppArmor (assuming it is in enforce mode) will deny access to the both newly added files. The reason is simply because the profile of the executable has not been updated. The profile only allows read access to the files mentioned in the profile, i.e. file_2.txt and file_3.txt, and everything else will be implicitly denied. If we would add read access to file_1.txt and file_4.txt to the existing profile, i.e. same as for the other two files, the result this time would be that reading of all files, except the file_4.txt file, would be allowed. The access to the file_4.txt file would still be denied, because the owner of the executable does not have access to that file. In this case, the DAC read permission rule would kick in and deny the access, and as we already know, AppArmor cannot grant more permissions than the owner of the executable already has.
 
-## Resource limit control
+### Resource Limit Control
 
 One of the important confinement possibilities with AppArmor is also resource limitations that can be set and controlled in profiles. Following are examples of resources that can be limited: maximum size of process’s memory, maximum CPU time, maximum size of files that a process may create, maximum size of memory that may be allocated in RAM, maximum number of processes that can be created by the calling process etc.
 
-The resource limitations are handled with kernel’s rlimits, which are also known as ulimits. According to the excerpt from the [getrlimit(2)](https://man7.org/linux/man-pages/man2/prlimit.2.html) Linux man page: “Each resource has an associated soft and hard limit. The soft limit is the value that the kernel enforces for the corresponding resource. The hard limit acts as a ceiling for the soft limit: an unprivileged process may only set its soft limit to a value in the range from 0 up to the hard limit, and (irreversibly) lower its hard limit. A privileged process (under Linux: one with the `CAP_SYS_RESOURCE` capability) may make arbitrary changes to either limit value.”  AppArmor can only control an executable’s hard limits and make sure the soft limits are not higher than the hard limits.
+The resource limitations are handled with kernel’s rlimits, which are also known as ulimits. According to the excerpt from the [getrlimit(2)](https://man7.org/linux/man-pages/man2/prlimit.2.html) Linux man page: *“Each resource has an associated soft and hard limit. The soft limit is the value that the kernel enforces for the corresponding resource. The hard limit acts as a ceiling for the soft limit: an unprivileged process may only set its soft limit to a value in the range from 0 up to the hard limit, and (irreversibly) lower its hard limit. A privileged process (under Linux: one with the `CAP_SYS_RESOURCE` capability) may make arbitrary changes to either limit value.”* AppArmor can only control an executable’s hard limits and make sure the soft limits are not higher than the hard limits.
 
 As with all other confinement possibilities AppArmor offers, it cannot raise the system’s rlimits, but only reduce what is already allowed by the system. If an executable would try to raise its hard rlimits to larger values than specified in its profile, AppArmor would prevent that. Profiles’ rlimits can only be either lower or equal to the system’s rlimits. When it comes to inheritance, a child will keep the same rlimts as its parent process and the rlimits will remain unchanged even if the executable becomes unconfined. Also, if an executable transfers to a new profile, e.g. if a new parent profile is created and the old executable becomes a child, in that new parent profile it is possible to further reduce rlimits. AppArmor does not provide any additional logging for rlimits.
 
@@ -538,7 +519,7 @@ The command to control the hard limit rule in AppArmor has the following syntax:
 
     set rlimit `resource` <=  `value`,
 
-The `resource` variable could be e.g. cpu, fsize, data, stack, core, rss, nofile, ofile, as, nproc, memlock, locks etc. For complete overview of all possible variables and corresponding `values` that can be specified for the rlimit rules, please check RLIMIT RULE syntax on Ubuntu manpage [apparmor.d - syntax of security profiles for AppArmor](http://manpages.ubuntu.com/manpages/xenial/man5/apparmor.d.5.html). Currently there is no tool that will automatically write a rlimit rule to a profile, hence it always needs to be inserted manually. If an update of a profile containing rlimits is made by e.g. the aa-logprof tool, it will not do any changes to the existing rlimit rules.
+The `resource` variable could be e.g. cpu, fsize, data, stack, core, rss, nofile, ofile, as, nproc, memlock, locks etc. For complete overview of all possible variables and corresponding `values` that can be specified for the rlimit rules, please check RLIMIT RULE syntax on Ubuntu manpage [apparmor.d - syntax of security profiles for AppArmor](http://manpages.ubuntu.com/manpages/xenial/man5/apparmor.d.5.html). Currently there is no tool that will automatically write a rlimit rule to a profile, hence it always needs to be inserted manually. If an update of a profile containing rlimits is made by e.g. the `aa-logprof` tool, it will not do any changes to the existing rlimit rules.
 
 To find out what soft and hard resource limits there are for a certain process, read the following file (replace PID with the real process ID number):
 
@@ -600,10 +581,9 @@ After putting the above profile in enforce mode and running the `max_file_size.s
 
 As seen from the above console output, the AppArmor rlimit rule kicks in and stops further writing to the file, which the script is writing to. This is a very simple and effective way to impose the file size limit to the running script that could potentially create an issue for our system if the default file size limit would be used instead.
 
+### Capabilities
 
-## Capabilities
-
-### Capabilities Introduction
+#### Capabilities Introduction
 Linux [capabilities](https://man7.org/linux/man-pages/man7/capabilities.7.html)
 provide a mechanism to enable unprivileged processes to utilize functionality
 usually reserved for privileged processes (those run as root) in a granular way.
@@ -636,11 +616,11 @@ and _"Thread capabilities"_ in
 Capabilities are a powerful tool which can easily be misused should a process with
 them be compromised, hence care has to be taken when assigning them. For example,
 in the absence of MAC, an executable which is assigned the
-capability CAP_DAC_OVERRIDE is allowed to override the DAC enforced by the system.
+capability `CAP_DAC_OVERRIDE` is allowed to override the DAC enforced by the system.
 This means that the executable can read and write to any file on the system and
 easily use this to elevate its own privileges to gain root privileges on the system.
 
-### Capabilities and AppArmor
+#### Capabilities and AppArmor
 To reduce the risk that is introduced by assigning capabilities AppArmor can be
 used to confine executables which have been granted capabilities. AppArmor
 restricts the capabilities an executable can invoke to those explicitly
@@ -692,7 +672,7 @@ following five criteria must be met:
 read and write permissions to a specific mount point.
 ```
 /path/to/executable {
-  # Allow capability 'CAP_SYS_ADMIN'
+  # Allow capability CAP_SYS_ADMIN
   capability sys_admin,
 
   # Allow 'path/to/fs' to be mounted at mount point '/path/to/mount_point/'
@@ -762,7 +742,7 @@ type as read-write or `sysfs` as read-only etc.
 /path/to/executable {
   #include <abstractions/base>
 
-  # Allow capability 'CAP_SYS_ADMIN'
+  # Allow capability CAP_SYS_ADMIN
   capability sys_admin,
 
   # Allow to execute the mount binary confined by the same profile as '/path/to/executable'
@@ -792,7 +772,7 @@ Anything under `/path/to/mount_point_2/` can be remounted, while
 /path/to/executable {
   #include <abstractions/base>
 
-  # Allow capability 'CAP_SYS_ADMIN'
+  # Allow capability CAP_SYS_ADMIN
   capability sys_admin,
 
   # Allow to execute the mount binary confined by the same profile as '/path/to/executable'
-- 
GitLab