- Let’s go over
some of the things you can do with containersthat you CANNOT do with Jails or Zones or VMs.
You can have your application running in one container, then in a different container sharing a net namespace you can run wireshark and inspect the packets from the first container.
You could also do the same with sharing a pid namespace , except instead of running wireshark you can run strace and debug your application from an entirely different container
This extra complexity leads to bugs that lead to container escapes. Don’t get me wrong you could also escape a VM, Jail or Zone, but the design is not as complicated as that of the primitives that make up containers.
You can get a sandbox level of isolation with containers, from your pieces of Seccomp, AppArmor , and SELinux profiles.
https://blog.jessfraz.com/post/containers-zones-jails-vms/
- We have derived four generalized use cases that should cover security requirements within the host-container threat landscape. The use cases include: (I) protecting a container from applications inside it, (II) inter-container protection, (III) protecting the host from containers, and (IV) protecting containers from a malicious or semi-honest host. We found that the first three use cases utilize a software-based solutions that mainly rely on Linux kernel features (e.g., namespaces, CGroups, capabilities, and seccomp) and Linux security modules (e.g., AppArmor). The last use case relies on hardware-based solutions such as trusted platform modules (TPMs) and trusted platform support (e.g., Intel SGX).
1) Use Case I: Protecting a Container From Applications Inside IT
In this use case, each application within a running container ci∈C can be honest, semi-honest, or malicious. We assume that applications cannot break access control policies if set. Additionally, we assume that some applications might require root privileges (or parts of the full root access).
2) Use Case II: Inter-Container Protection
In this use case, we assume that one or more of the containers are semi-honest or malicious
These containers can be inside the host H or on different hosts. Being on different hosts is important for the emerging field of service meshes
3) Use Case III: Protecting the Host (And the Applications Inside it) From Containers.In this use case, we assume that at least one container is semi-honest or malicious within the host.A semi-honest container can have access to confidential host information or even target its integrity. A malicious container can target the host’s availability by consuming its resources.
4) Use Case IV: Protecting Containers from the Host
Running containers on untrusted hosts should be avoided, especially with the advent of CaaS where containers can be rented from a CaaS provider. In this use case, we assume that containers are honest but the host is either semi-honest or malicious. A semi-honest host can learn about confidential container information because it controls network devices, memory, storage, and processors. A malicious host can also target the integrity of the container and its application(s). Numerous passive and active attacks can be launched from semi-honest and malicious hosts against containers in them. Examples of passive attacks include profiling in-container application activities and unauthorized access for container data. Active attacks can be more harmful since a malicious host can change the application’s behavior.
Software and Hardware Protection Mechanisms
A. Software-Based Protection Mechanisms
Container technology relies heavily on software-based solutions that are either Linux Security Features (LSFs) or Linux Security Modules (LSMs).
1) Linux Kernel Features
a: Namespaces
Namespaces perform the job of isolation and virtualization of system resources for a collection of processes. Namespaces operate as a divider of the identifier tables and other structures linked with kernel global resources into isolated instances. They partition the file systems, processes, users, hostnames, and other components. Hence, each file system namespace will have its private mount table and root directory. For every container, a unique view of the resources can be seen. The constrained view of resources for a process within a container can be extended also to a child process.Namespaces ensure the isolation of processes that are running in a container to blind them from seeing other processes running in a different container.However, one issue with namespaces is that some resources are still not namespace-aware such as devices.There are numerous namespaces available, each of which is responsible for specific resource isolation.
Solutions that use namespaces
They presented a defense technique that tries to solve the escape attack based on namespace status inspection during process execution.This should help in detecting anomalies and further prevent escape attacks.
b: Control Groups (CGroups)
CGroups are Linux features that control the accountability and limitation of resource usage such as central processing unit (CPU) runtime, system memory, input/output (I/O), and network bandwidth. In contrast to namespaces, CGroups limit how many resources can be used while namespaces control what resources a container can see (i.e., isolation).Additionally, CGroups prevent containers from using all the available resources and starving other processes.A CGroup is arranged as a slice for each resource. Then a task set can be attached to each specific CGroup. Thus, task groups are forced to use their own part of the resource
Inter-container protection using CGroups (Use case II)
CGroups are vital for inter-container protection requirements. As discussed, CGroups circumscribe the allowed resource usage, hence, a container cannot use more resources than what is designated for it. This helps protect other containers from numerous attacks such as Denial-of-Service (DoS) attacks. For example, a container may use so much of the host’s available RAM that other containers cannot operate properly
Protecting the host from containers using CGroups (Use case III)
CGroups force resource usage limits on containers. This helps prevent the container from performing a DoS attack on the host itself. Additionally, CGroups give the host the power to not only limit resource usage but also account for how much of the resource is used. This could help in implementing usage quotas which can be a very important factor in the emerging cloud computing delivery model CaaS.
Solutions that use CGroups
Then, for memory DoS protection, the authors demonstrated experimentally that CGroups are not efficient because although they can restrict the allocated memory bandwidth, malicious applications could still use intensive access for that amount of memory. Hence, to protect memory from DoS attacks they used a MemGuard kernel module to prevent each CPU core from exceeding memory access.
c: Capabilities
Linux systems implement the binary option of root and non-root dichotomy. In the context of containers, those binary options can be troublesome. For example, a web server (e.g., Apache) needs to bind on a specific port (e.g., TCP port 80). Without using capabilities, the web server process should have root access to perform its task. This poses a great danger because if it gets compromised, an attacker will be able to control the entire system. Capabilities turn the root and non-root dichotomy into fine-grained access control.Hence, containers (usually not the daemon or container manager) will not need to have full root privilege (assuming there is an available capability for the required tasks). There are thirty-eight capabilities that cover a wide variety of tasks
For our previous example about web servers, a container can assign the process the CAP_NET_BIND_SERVICE capability. This allows the container to run a version of that web server without requiring full root access. Assuming the web server contains a vulnerability that has been exploited by an adversary, having this capability in place will circumscribe the adversary to a single root operation (i.e., binding ports). On the other hand, if the capability was not set, the compromised or malicious application can perform full root operations on the container.
In addition, capabilities are important for protecting the host from containers.In the previous example, we saw that a container can limit its applications but what happens if the container itself is malicious? This causes a direct risk to the host. Thus, a set of capabilities can be assigned to the container which could reduce the container’s root operational threats.
d: Secure Computation Mode (Seccomp)
Seccomp is a Linux kernel feature that filters system calls to the kernel. Secomp is more fine-grained than capabilities.This helps to decrease the number of system calls coming from containers, which could further reduce possible threats since most attacks leverage kernel exploits through system calls.
Solutions that use Seccomp
Split-Phase Execution of Application Containers (SPEAKER) aiming to differentiate between necessary and unnecessary system calls made by containers.
a solution to mine sandboxes for containers based on automatic testing. During the testing phase, the proposed solution extracts the used system calls by the container. Using Seccomp, the solution creates a profile for each application based on the seen system calls during the testing phase and denies all other calls
e: Namespaces, CGroups, Seccomp, and Capabilities Use in Docker
Docker uses namespaces and CGroups to create a safe virtual environment for its containers.For example, to offer a separate network for each container, the network namespace isolates some network resources like Internet protocol (IP) addresses.Docker depends on CGroups to group processes running in the container. CGroups reveal metrics about CPU and I/O block usage along with managing the resources of Docker such as CPU and memory. Docker resource configurations are either with hard or soft limits. Hard limits are used to specify a specific amount of resources to the container. Soft limits give the container the necessary resources in the machine.The issue with capabilities as expressed by the Docker team in is that the default set of capabilities might not provide complete security isolation.Docker adds support for adding and removing capabilities. Additionally, users can set their own profile.We should note here that as the number of capabilities added to the container increases there will be a higher security risk. This is because the container will be able to perform more root privileged tasks.The default seccomp profile of Docker blocks 44 out of 300 available system calls
2) Linux Security Modules (LSMs)
enhanced access control mechanisms are not accepted widely to maintain OSs. This is due to the fact that there is no consensus on the right solution within the security community.LSMs allow a wide variety of security models to be implemented on Linux kernel as loadable modules.This means that a user can select the preferred implementation rather than being forced to use the one that came with the OS. LSMs focus on providing the needs for implementing Mandatory Access Control (MAC) with minimal changes to the Kernel itself.In case of not specifically selecting an LSM then the default LSM will be the Linux capabilities system.One of the primary issues with LSMs is that they are shared by all containers, wherein a single container cannot use a specific LSM.
B. Hardware-Based Protection Mechanisms
This section addresses solutions to protect containers from a semi-honest or malicious host as well as other containers.We address two available mechanisms: The use of Virtual Trusted Platform Modules (vTPMs) and the use of Intel SGX as a trusted platform support mechanism
1) Virtual Trusted Platform Modules (vTPM)
One commonly used technique in trusted computing is Trusted Platform Modules (TPMs) which is hardware that is intended to be used as a cryptographic processor. TPMs provide hardware support for attestation, sealing data, secure boot, and algorithm acceleration
a: vTPM in Host OS Kernel
b: vTPM in a Dedicated Container
2) Intel SGX
Intel SGX is a set of extensions that allows Intel architecture hardware to provide confidentiality and integrity guarantees when the underlying privileged software (e.g., hypervisor, kernel) is potentially malicious. Intel SGX seamlessly protects containers from underlying layers (e.g., cloud provider, or host machine).
Other Aspects of Containers Security
There are two other important aspects to maintain container security: vulnerabilities management and standard guidelines.
Open Issues and Future Research Directions
A. Meltdown and Spectre Attacks
Meltdown exploits the out-of-order execution in modern processors to extract information about the OS and other containers. Containers are based on the concept of sharing the same kernel.Spectre is another serious threat to containers, as it tricks other applications into accessing arbitrary locations in their memory
B. Standards for Container Security
Further investigation for standardization of container deployment, communication protocols, and assessment methodologies is required
C. Digital Forensics for Containers
Digital forensics is used to analyze security incidents. As the world is moving towards microservices that use containers, digital forensic techniques should be able to analyze security incidents related to them
D. Usability of Vulnerabilities Assessment Tools
Several researchers showed that Docker images contain many high-risk vulnerabilities
E. Container Alternatives
The study shows that VMs and unikernels provide good isolation compared to containers. However, VMs are inefficient because they are large, unikernels are not optimal because they lack privilege levels (which help separate kernel code from application code), and containers do not provide as good isolation as VMs or unikernels.
F. Container Security and Privacy for IoT Applications
we re-emphasize the importance of studying container security, privacy, and standardization technologies for different IoT applications such as smart grids, smart vehicles, augmented reality, smart sensor networks, E-Health, and network function virtualization (NFV).
G. Blockchain for Container Verification
Notary can be used to verify Docker images’ authenticity, however, is a centralized solution. A better solution is to use a decentralized verification that could use a blockchain.
H. Container Specific LSMs
One issue with LSMs is that they are shared by all containers, in which a single container cannot use a specific LSM. LSMs play a pivotal role in providing security for Linux systems in general.However, sharing LSMs among different containers can be crippling as different containers might have different protection requirements.
Conclusions
Containers are important for the future of cloud computing. Microservices and containers are closely related, where containers are considered the standardized way for microservice deployment. Containers are important for the emerging field of service meshes that relies on microservices, too.
https://ieeexplore.ieee.org/document/8693491
