User story for "Container should execute process(es) as non-root user" best practice

--- tags: --- # User story for "Container should execute process(es) as non-root user" best practice References: - Hackmd [CBPP: No root in containers / Container should execute process as non-root user](https://hackmd.io/xp6Y2XsaQsK5Ix7XytbTMA) - Pull Request: [Initial draft for a not running processes as root in containers as a best practice #182](https://github.com/cncf/cnf-wg/pull/182) --- ## Firewall CNF downloads compromised updates A firewall running on a K8s cluster applies configuration from an external, centralized system. Software updates are also pulled directly into the running container using a hot code reloading update procedure. Unfortunately, the latest update has been compromised on the central system and looks like a valid update for the firewall application. The firewall downloads the application and the compromised code is able to take over the containers process with its own malicious code. With this best practice, the now malicious firewall CNF will not be able to escalate its damage beyond what the non-root user has access to. --- ## A combo Firewall-Router downloads compromised updates An Firewall-Router VNF was containerized and is running on a K8s cluster. It uses OpenVSwitch (OVS) for the routing and switching capabilities, while the firewall is handled by another process with its own configuration. The OVS process retrieves its routing scripts and logic, which are defined externally, from a remote service. It then applies them to the running container instance. Unfortunately, the latest resources it downloaded have been compromised. The OpenVSwitch runs the compromised code which takes over the container’s process with its own malicious code. If the OVS process runs as the root user it will be able to modify the firewall process and its configuration as well as its own. If instead, OVS runs as a non-root user unique to its own process, it will be limited to what the non-root user has access to, eg. its own files and capabilities. ## A Firewall as a Service (FWaaS) CNF downloads compromised externally defined rules A firewall running on a K8s cluster applies rules from an external, centralized system. These firewall rules are applied “hot” to the running container and are expected to be pre-validated by the external system. Unfortunately, the latest set of rules include an exploit while still passing validation by the external system and the firewall CNF itself. The firewall downloads the newly defined rules with the exploit and when they are applied the firewall container is compromised with malicious code. With this best practice, the now malicious firewall CNF will not be able to escalate its damage beyond what the non-root user has access to. ## A containerized OpenVSwitch downloads compromised updates A OpenVSwitch VNF was containerized and is running on a K8s cluster. It retrieves its routing scripts and logic are defined an externally from remote service. It then applies them to the running container instance. Unfortunately, the latest resources it downloaded have been compromised on the central system. The OpenVSwitch runs compromised code which takes over the container’s process with its own malicious code. With this best practice, the now malicious application will not be able to escalate its damage beyond what the non-root user has access to. ## A CNF downloads compromised updates A CNF running on a K8s cluster is downloaded from a centralized registry. Updates also come from this registry. The operator installs new images in the centralised repository as they receive them from the CNF developer. Supply chain attacks are a risk at any point in the supply chain. In a supply chain attack, a malicious actor sneaks code into the application that serves their nefarious purposes. It can happen for many reasons: for instance, because they managed to modify the registry, they managed to modify the image before it was placed in the registry, or they managed to get illicit code into an open source project that is built into the container. 'Defence in depth' says that we should (a) defend against supply chain attacks but also (b) add mitigations in the case that supply chain attacks happen - that is, we should not assume that a single line of defence will hold. In this case, if the operator ensures that processes in the container will be run as a normal conatiner user without extra rights, the malicious code will have a very limited ability to do dangerous things. It will be harder for it to try to escalate its privileges, it has no rights outside of the conatiner, it cannot change files within the container that could cause more damage (such as root-owned settings files in /etc). Thus: limiting the privilege of container processes makes the system safer to use. ## A CNF succumbs to code injection As above, a CNF runs malicious code, in this case introduced into the process through a code injection attack on its internal or external interfaces by a bad actor within the operator's organisation or by anyone on the network, respectively). In this instance, limiting the power wielded by processes in the conatiner again prevents the attack from going further. ## A CNF succumbs to malicious instructions As an example: the configuration of a CNF might allow the operator to determine paths where a log file is written. If this path is set to a protected file, then the conatiner root user has the rights necessary to overwrite that file. This could be exploited to change configuration and settings files within the conatiner image and subvert it. A CNF such as a programmable forwarder might receive rules updates from a central system. Maliciously crafted rules might cause the process to attempt to do operations within its container that would compromise the container's security. While it takes a successful attack to get malicious rules into the feed of updates, this means that such an attack can escalate to container control and perhaps further. This can be limited if the process in the container is an unprivileged process running as a normal user without any capabilities, meaning that it cannot write files owned by other users. > [name=Taylor Carpenter] this last one could be used for privilege=false as well ## A CNF has a security-compromising bug A CNF unwittingly has a bug where an appropriately crafted packet will write a file at a location on the disk dependent on the packet's content. This can lead to compromise. Many possibilities for compromise are prevented if the process in question does not have overarching power to write the filesystem, as is typically available to a container root user. A CNF may also have a bug where it attempts to rewrite settings files that keep the CNF secure (e.g. files containing credentials). If the file is not owned by the process and the process is not itself a root process it has no power to change those files. --- ## Supply chain attack user stories Supply chain attacks are a risk at any point in the supply chain. In a supply chain attack, a malicious actor sneaks code into the application that serves their nefarious purposes. It can happen for many reasons: for instance, because they managed to modify the registry, they managed to modify the image before it was placed in the registry, or they managed to get illicit code into an open source project that is built into the container. ‘Defence in depth’ says that we should (a) defend against supply chain attacks but also (b) add mitigations in the case that supply chain attacks happen - that is, we should not assume that a single line of defence will hold. Examples include - A CNF downloads compromised updates - A CNF succumbs to code injection - A CNF succumbs to malicious instructions - A CNF has a security-compromising bug