BZ2079092: add SELinux warnings and fix hard returns

Author: jldohmann

modules/security-hardening-how.adoc

@@ -6,53 +6,34 @@
 
 = Choosing how to harden {op-system}
 
-Direct modification of {op-system} systems in {product-title} is discouraged.
-Instead, you should think of modifying systems in pools of nodes, such
-as worker nodes and control plane nodes. When a new node is needed, in
-non-bare metal installs, you can request a new node of the type
-you want and it will be created from an {op-system} image plus the
-modifications you created earlier.
+Direct modification of {op-system} systems in {product-title} is discouraged. Instead, you should think of modifying systems in pools of nodes, such as worker nodes and control plane nodes. When a new node is needed, in non-bare metal installs, you can request a new node of the type you want and it will be created from an {op-system} image plus the modifications you created earlier.
 
-There are opportunities for modifying {op-system} before installation,
-during installation, and after the cluster is up and running.
+There are opportunities for modifying {op-system} before installation, during installation, and after the cluster is up and running.
 
 [id="security-harden-before-installation_{context}"]
 == Hardening before installation
 
-For bare metal installations, you can add hardening features to
-{op-system} before beginning the {product-title} installation. For example,
-you can add kernel options when you boot the {op-system} installer
-to turn security features on or off, such as SELinux or various
-low-level settings, such as symmetric multithreading.
+For bare metal installations, you can add hardening features to {op-system} before beginning the {product-title} installation. For example, you can add kernel options when you boot the {op-system} installer to turn security features on or off, such as various SELinux booleans or low-level settings, such as symmetric multithreading.
 
-Although bare metal {op-system} installations are more difficult,
-they offer the opportunity of getting operating system
-changes in place before starting the {product-title} installation. This can be important when you need to ensure that certain
-features, such as disk encryption or special networking settings, be
-set up at the earliest possible moment.
+[WARNING]
+====
+Disabling SELinux on {op-system} nodes is not supported.
+====
+
+Although bare metal {op-system} installations are more difficult, they offer the opportunity of getting operating system changes in place before starting the {product-title} installation. This can be important when you need to ensure that certain features, such as disk encryption or special networking settings, be set up at the earliest possible moment.
 
 [id="security-harden-during-installation_{context}"]
 == Hardening during installation
 
-You can interrupt the {product-title} installation process and change
-Ignition configs. Through Ignition configs, you can add your own files
-and systemd services to the {op-system} nodes.
-You can also make some basic security-related changes to the `install-config.yaml` file
-used for installation.
-Contents added in this way are available at each node's first boot.
+You can interrupt the {product-title} installation process and change Ignition configs. Through Ignition configs, you can add your own files and systemd services to the {op-system} nodes. You can also make some basic security-related changes to the `install-config.yaml` file used for installation. Contents added in this way are available at each node's first boot.
 
 [id="security-harden-after-installation_{context}"]
 == Hardening after the cluster is running
-After the {product-title} cluster is up and running, there are
-several ways to apply hardening features to {op-system}:
+After the {product-title} cluster is up and running, there are several ways to apply hardening features to {op-system}:
 
 * Daemon set: If you need a service to run on every node, you can add
-that service with a
-link:https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/[Kubernetes `DaemonSet` object].
-* Machine config: `MachineConfig` objects contain a subset of Ignition configs in the same format.
-By applying machine configs to all worker or control plane nodes,
-you can ensure that the next node of the same type that is added
-to the cluster has the same changes applied.
-
-All of the features noted here are described in the {product-title}
-product documentation.
+that service with a link:https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/[Kubernetes `DaemonSet` object].
+
+* Machine config: `MachineConfig` objects contain a subset of Ignition configs in the same format. By applying machine configs to all worker or control plane nodes, you can ensure that the next node of the same type that is added to the cluster has the same changes applied.
+
+All of the features noted here are described in the {product-title} product documentation.

modules/security-hosts-vms-rhcos.adoc

@@ -5,66 +5,30 @@
 [id="security-hosts-vms-rhcos_{context}"]
 = Securing containers on {op-system-first}
 
-Containers simplify the act of deploying many applications to run on the same host,
-using the same kernel and container runtime to spin up each container.
-The applications can be owned by many users and, because they are kept
-separate, can run different, and even incompatible, versions of those applications
-at the same time without issue.
+Containers simplify the act of deploying many applications to run on the same host, using the same kernel and container runtime to spin up each container. The applications can be owned by many users and, because they are kept separate, can run different, and even incompatible, versions of those applications at the same time without issue.
 
-In Linux, containers are just a special type of process, so securing
-containers is similar in many ways to securing any other running process.
-An environment for running containers starts with an operating system
-that can secure the host kernel from
-containers and other processes running on the host, as well as
-secure containers from each other.
+In Linux, containers are just a special type of process, so securing containers is similar in many ways to securing any other running process. An environment for running containers starts with an operating system that can secure the host kernel from containers and other processes running on the host, as well as secure containers from each other.
 
-Because {product-title} {product-version} runs on {op-system} hosts,
-with the option of using {op-system-base-full} as worker nodes,
-the following concepts apply by default to any deployed {product-title}
-cluster. These {op-system-base} security features are at the core of what
-makes running containers in {product-title} more secure:
+Because {product-title} {product-version} runs on {op-system} hosts, with the option of using {op-system-base-full} as worker nodes, the following concepts apply by default to any deployed {product-title} cluster. These {op-system-base} security features are at the core of what makes running containers in {product-title} more secure:
 
-* _Linux namespaces_ enable creating an abstraction of a particular global system
-resource to make it appear as a separate instance to processes within a
-namespace. Consequently, several containers can use the same computing resource
-simultaneously without creating a conflict.
-Container namespaces that are separate from the host by default include mount table, process table,
-network interface, user, control group, UTS, and IPC namespaces.
-Those containers that need direct access to host namespaces need to have
-elevated permissions to request that access.
+* _Linux namespaces_ enable creating an abstraction of a particular global system resource to make it appear as a separate instance to processes within a namespace. Consequently, several containers can use the same computing resource simultaneously without creating a conflict. Container namespaces that are separate from the host by default include mount table, process table, network interface, user, control group, UTS, and IPC namespaces. Those containers that need direct access to host namespaces need to have elevated permissions to request that access.
 ifdef::openshift-enterprise,openshift-webscale,openshift-aro[]
-See
-link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/building_running_and_managing_containers/index[Overview of Containers in Red Hat Systems]
-from the {op-system-base} 8 container documentation for details on the types of namespaces.
+See link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/building_running_and_managing_containers/index[Overview of Containers in Red Hat Systems] from the {op-system-base} 8 container documentation for details on the types of namespaces.
 endif::[]
 
-* _SELinux_ provides an additional layer of security to keep containers isolated
-from each other and from the host. SELinux allows administrators to enforce
-mandatory access controls (MAC) for every user, application, process, and file.
+* _SELinux_ provides an additional layer of security to keep containers isolated from each other and from the host. SELinux allows administrators to enforce mandatory access controls (MAC) for every user, application, process, and file.
 
-* _CGroups_ (control groups) limit, account for, and isolate the resource usage
-(CPU, memory, disk I/O, network, etc.) of a collection of processes. CGroups are
-used to ensure that containers on the same host are not impacted by each other.
+[WARNING]
+====
+Disabling SELinux on {op-system} is not supported.
+====
 
-* _Secure computing mode (seccomp)_ profiles can be associated with a container to
-restrict available system calls. See page 94 of the
-link:https://access.redhat.com/articles/5059881[OpenShift Security Guide] for details about seccomp.
+* _CGroups_ (control groups) limit, account for, and isolate the resource usage (CPU, memory, disk I/O, network, etc.) of a collection of processes. CGroups are used to ensure that containers on the same host are not impacted by each other.
 
-* Deploying containers using _{op-system}_ reduces the attack surface by
-minimizing the host environment and tuning it for containers.
-The link:https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/cri-o_runtime/index[CRI-O container engine] further reduces that attack surface by
-implementing only those features required by Kubernetes and {product-title} to
-run and manage containers, as opposed to other container engines
-that implement desktop-oriented standalone features.
+* _Secure computing mode (seccomp)_ profiles can be associated with a container to restrict available system calls. See page 94 of the link:https://access.redhat.com/articles/5059881[OpenShift Security Guide] for details about seccomp.
 
-{op-system} is a version of {op-system-base-full} that is specially
-configured to work as control plane (master) and worker nodes
-on {product-title} clusters.
-So {op-system} is tuned to efficiently run container workloads, along with
-Kubernetes and {product-title} services.
+* Deploying containers using _{op-system}_ reduces the attack surface by minimizing the host environment and tuning it for containers. The link:https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/cri-o_runtime/index[CRI-O container engine] further reduces that attack surface by implementing only those features required by Kubernetes and {product-title} to run and manage containers, as opposed to other container engines that implement desktop-oriented standalone features.
 
-To further protect {op-system} systems in {product-title} clusters,
-most containers, except those managing or monitoring the host system itself,
-should run as a non-root user. Dropping the privilege level or
-creating containers with the least amount of privileges possible is recommended
-best practice for protecting your own {product-title} clusters.
+{op-system} is a version of {op-system-base-full} that is specially configured to work as control plane (master) and worker nodes on {product-title} clusters. So {op-system} is tuned to efficiently run container workloads, along with Kubernetes and {product-title} services.
+
+To further protect {op-system} systems in {product-title} clusters, most containers, except those managing or monitoring the host system itself, should run as a non-root user. Dropping the privilege level or creating containers with the least amount of privileges possible is recommended best practice for protecting your own {product-title} clusters.