mitigations.md

Mitigation Strategies Analysis for containers/podman

Mitigation Strategy: Enable Image Signature Verification in Podman

• Mitigation Strategy: Enable Image Signature Verification in Podman
• Description:
  1. Configure policy.json: Modify the policy.json file (usually located in /etc/containers/policy.json or ~/.config/containers/policy.json) to enforce signature verification for image pulls.
  2. Set default policy to reject or trustfirst: Change the default policy within policy.json to either reject (rejects unsigned images) or trustfirst (accepts signed images, warns for unsigned). For stricter security, reject is recommended.
  3. Configure specific trust policies (optional): For specific registries or image names, define more granular trust policies within policy.json to allow signed images from trusted sources while rejecting others.
  4. Test verification: Test image pulling with Podman to ensure signature verification is enforced as configured. Attempt to pull an unsigned image to confirm rejection (if reject policy is used).
• List of Threats Mitigated:
  • Image Tampering/Integrity Issues (High Severity): Ensures that pulled images have not been tampered with since they were signed by the image publisher, protecting against malicious modifications.
  • Man-in-the-Middle Attacks during Image Pull (Medium Severity): Reduces the risk of attackers intercepting and modifying images during the pull process, as signature verification will detect alterations.
  • Accidental Use of Unofficial Images (Low Severity): Provides a mechanism to verify the authenticity and origin of images, reducing the chance of unintentionally using unofficial or untrusted images.
• Impact: Moderately Reduces risk of image tampering and ensures image integrity by leveraging Podman's built-in signature verification capabilities.
• Currently Implemented: (Example - Replace with your project's status)
  • Signature verification is not currently enforced in Podman configurations. policy.json is using the default permissive settings.
• Missing Implementation: (Example - Replace with your project's status)
  • policy.json needs to be updated to enforce signature verification, ideally using the reject policy for maximum security. Configuration management tools should be used to deploy the updated policy.json across all Podman hosts.

Mitigation Strategy: Implement Resource Limits using Podman Flags

• Mitigation Strategy: Implement Resource Limits using Podman Flags
• Description:
  1. Determine resource needs: Analyze the resource requirements (CPU, memory, disk I/O) for each containerized application.
  2. Use Podman run flags: When running containers with podman run, utilize flags like --memory, --cpus, --cpu-shares, --blkio-weight to define resource limits for each container.
  3. Incorporate limits in container definitions: If using Podman Compose or other orchestration tools, define resource limits within the container definitions using the appropriate syntax for Podman.
  4. Monitor resource usage with Podman stats: Use podman stats command to monitor container resource consumption and verify that limits are being enforced.
  5. Adjust limits based on monitoring: Regularly review resource usage data and adjust container resource limits as needed to optimize performance and security.
• List of Threats Mitigated:
  • Denial of Service (DoS) due to Resource Exhaustion (High Severity): Prevents a single container from consuming excessive resources and impacting other containers or the host system, mitigating resource exhaustion DoS attacks.
  • "Noisy Neighbor" Problem (Medium Severity): Reduces the impact of one container's resource usage on the performance of other containers sharing the same host, improving overall system stability.
  • Container Escape due to Resource Starvation (Low Severity): In some edge cases, resource starvation within a container could lead to unexpected behavior exploitable for container escape; resource limits can help prevent this.
• Impact: Moderately Reduces risk of DoS and resource contention by directly leveraging Podman's resource management flags to control container resource consumption.
• Currently Implemented: (Example - Replace with your project's status)
  • Resource limits are inconsistently applied using Podman run flags. Some containers have memory limits set, but CPU and I/O limits are rarely configured.
• Missing Implementation: (Example - Replace with your project's status)
  • Resource limits need to be systematically applied to all containers using Podman run flags or container definition files. Standardized resource limit configurations should be defined and enforced across deployments.

Mitigation Strategy: Utilize Security Profiles (SELinux/AppArmor) with Podman

• Mitigation Strategy: Utilize Security Profiles (SELinux/AppArmor) with Podman
• Description:
  1. Ensure SELinux or AppArmor is enabled on host: Verify that SELinux or AppArmor is enabled and running on the host operating system. Podman leverages these systems if available.
  2. Understand default Podman profiles: Podman applies default SELinux or AppArmor profiles to containers automatically. Understand these default profiles and their restrictions.
  3. Create custom profiles (if necessary): If default profiles are insufficient or too permissive, create custom SELinux or AppArmor profiles tailored to the specific needs of your application containers.
  4. Apply custom profiles using --security-opt: Use the --security-opt flag with podman run to specify custom SELinux or AppArmor profiles for containers. For SELinux, use label=type:<profile_type>. For AppArmor, use apparmor=profile=<profile_name>.
  5. Test profile enforcement: Test container functionality with the applied security profiles to ensure they are effective and do not break application functionality. Audit logs for SELinux/AppArmor denials to refine profiles.
• List of Threats Mitigated:
  • Container Escape Vulnerabilities (High Severity): Limits the capabilities available to a container, making it significantly harder to exploit kernel vulnerabilities or misconfigurations for container escape by enforcing mandatory access control.
  • Host System Compromise from Container (High Severity): Reduces the potential impact of a compromised container on the host system by restricting container access to host resources and system calls through security profiles.
  • Lateral Movement within Container Environment (Medium Severity): Limits the actions a compromised container can take within the container environment by restricting its capabilities and access using profile-based restrictions.
• Impact: Significantly Reduces risk of container escape and host system compromise by leveraging Podman's integration with SELinux/AppArmor to enforce mandatory access control.
• Currently Implemented: (Example - Replace with your project's status)
  • SELinux is enabled on the host, and Podman is using default SELinux profiles. Custom profiles are not currently used.
• Missing Implementation: (Example - Replace with your project's status)
  • Custom SELinux or AppArmor profiles tailored to our application containers need to be developed and deployed. The --security-opt flag should be consistently used in Podman run commands or container definitions to apply these custom profiles.

Mitigation Strategy: Isolate Container Networks using Podman Networking

• Mitigation Strategy: Isolate Container Networks using Podman Networking
• Description:
  1. Utilize Podman network modes: When running containers, explicitly choose appropriate Podman network modes. Use bridge mode for isolated networks, container:<id> to share network namespace with another container, or none for no network access. Avoid host mode unless absolutely necessary.
  2. Create custom bridge networks with podman network create: Create custom bridge networks using podman network create to isolate groups of containers that need to communicate with each other but should be separated from other networks.
  3. Connect containers to specific networks with --network: Use the --network flag with podman run to connect containers to specific custom bridge networks or the default bridge network.
  4. Implement network policies (using plugins or host firewall): For more advanced network isolation and control, explore Podman network plugins or configure host-based firewalls (like iptables or firewalld) to further restrict traffic between container networks and the host/external networks.
• List of Threats Mitigated:
  • Lateral Movement between Containers (Medium Severity): Prevents compromised containers from easily communicating with and potentially compromising other containers by isolating them in separate networks.
  • Exposure of Container Services to Host Network (Medium Severity): Reduces the risk of unintentionally exposing container services to the host network and potentially wider networks by avoiding host networking and using isolated bridge networks.
  • Network-based Attacks from Compromised Containers (Medium Severity): Limits the ability of a compromised container to launch network-based attacks against other containers or the host network by controlling network connectivity.
• Impact: Moderately Reduces risk of lateral movement and network-based attacks by leveraging Podman's networking features to isolate containers and control network communication.
• Currently Implemented: (Example - Replace with your project's status)
  • Containers are generally deployed using the default Podman bridge network. Custom bridge networks are not widely used. host networking is occasionally used for specific use cases.
• Missing Implementation: (Example - Replace with your project's status)
  • Custom bridge networks should be implemented to isolate different application components or environments. host networking should be strictly avoided unless there is a strong justification and security review. Network policies or firewalls for container networks are not yet implemented.

Mitigation Strategy: Implement Principle of Least Privilege for Podman Volume Mounts

• Mitigation Strategy: Implement Principle of Least Privilege for Podman Volume Mounts
• Description:
  1. Mount only necessary paths with --volume: When using podman run with the --volume flag (or -v), carefully specify only the essential host paths that need to be mounted into containers. Avoid mounting entire directories unnecessarily.
  2. Use read-only mounts with :ro: Whenever containers only require read access to mounted data, use the :ro mount option to mount volumes as read-only. This prevents containers from modifying host files.
  3. Define specific mount points within container: Mount volumes to specific, non-privileged locations within the container filesystem, rather than mounting them to root (/) or other sensitive directories.
  4. Avoid mounting sensitive host directories: Never mount sensitive host directories like /etc, /var, /root, or user home directories into containers unless absolutely necessary and with extreme caution.
  5. Use tmpfs volumes for temporary data with --tmpfs: For temporary data that does not need to persist on the host, use podman run --tmpfs to create tmpfs volumes, which reside in memory and are more secure than host directory mounts for temporary files.
• List of Threats Mitigated:
  • Container Escape via Volume Mounts (High Severity): Reduces the risk of container escape by limiting the container's writable access to the host filesystem and preventing access to sensitive host directories through volume mounts.
  • Host System Compromise via Volume Mounts (High Severity): Limits the potential damage a compromised container can inflict on the host system by restricting its ability to modify host filesystems through controlled volume mounts.
  • Data Leakage via Volume Mounts (Medium Severity): Prevents accidental or malicious data leakage from the host system into containers or vice versa by carefully controlling which directories are shared and with what permissions.
• Impact: Significantly Reduces risk of container escape and host system compromise by enforcing least privilege principles when configuring Podman volume mounts.
• Currently Implemented: (Example - Replace with your project's status)
  • Volume mounts are used, but the principle of least privilege is not consistently applied. Read-only mounts are not always used when applicable. Mounting of sensitive host directories is generally avoided, but not strictly enforced.
• Missing Implementation: (Example - Replace with your project's status)
  • Read-only mounts should be used by default where containers only need to read data. Automated checks should be implemented to verify volume mount configurations and flag overly permissive or risky mounts. tmpfs volumes should be used more extensively for temporary data.

Mitigation Strategy: Secure Podman API Access (If Exposed)

• Mitigation Strategy: Secure Podman API Access (If Exposed)
• Description:
  1. Enable TLS for API endpoint: If exposing the Podman API remotely, configure Podman to use TLS encryption for the API endpoint. This is typically done by configuring certificates and keys in the Podman service configuration.
  2. Implement authentication and authorization: Enable authentication and authorization mechanisms for the Podman API. Podman supports various authentication methods; choose a strong method appropriate for your environment (e.g., client certificates, OAuth 2.0).
  3. Restrict API access to trusted networks/IPs: Configure firewalls or network access control lists (ACLs) to restrict access to the Podman API endpoint to only trusted networks or specific IP addresses.
  4. Regularly audit API access logs: Enable and regularly review Podman API access logs to detect any suspicious or unauthorized activity. Monitor for unusual API calls or access attempts from unexpected sources.
  5. Consider disabling remote API access if not required: If remote API access is not essential, consider disabling it entirely to eliminate the attack surface.
• List of Threats Mitigated:
  • Unauthorized Access to Podman API (High Severity): Prevents unauthorized users or systems from accessing and controlling the Podman daemon, which could lead to container manipulation, data breaches, or system compromise.
  • API Credential Theft/Compromise (High Severity): Protects API credentials (if used) from being intercepted or stolen during transmission by using TLS encryption and strong authentication.
  • Remote Code Execution via API Vulnerabilities (High Severity): Reduces the risk of remote code execution vulnerabilities in the Podman API being exploited by limiting access to authorized and authenticated users.
• Impact: Significantly Reduces risk of unauthorized access and control of the Podman daemon by securing the API endpoint and implementing access controls.
• Currently Implemented: (Example - Replace with your project's status)
  • The Podman API is currently exposed without TLS encryption and without authentication. API access is open to the network where Podman is running.
• Missing Implementation: (Example - Replace with your project's status)
  • TLS encryption needs to be enabled for the Podman API endpoint. Strong authentication and authorization mechanisms must be implemented. Network access to the API should be restricted to only authorized systems. API access logging needs to be enabled and monitored.