Security patches and bug fixes for the kernel and OS software are released as issues are resolved. Keep the OS current with the most recent software updates. Subscribe the system to the latest software channels or repositories, and run regular DNF update operations. Consider using Ksplice to keep the system software up-to-date.

Where possible, use a minimal OS installation and ensure that it follows the security best practices described in the following documents:

• Oracle Linux 8: Enhancing System Security
• Oracle Linux 9: Enhancing System Security
• Oracle Linux 10: Enhancing System Security

Most importantly, reduce the number of services running on the same system. Ideally, move all other services to reside within containers controlled by Podman or move them to other systems entirely. This helps to contain damage in the event of container break out.

Be vigilant that the OS is regularly scrutinized for safety and potential vulnerabilities.

We recommend keeping all system components, including the kernel, up-to-date so that all known security and functionality issues have been resolved. If you're using the Unbreakable Enterprise Kernel (UEK), consider using the latest available UEK generation for the Oracle Linux release, so that kernel-based features such as kernel namespaces, private networking, and control groups are mature, reliable, and heavily tested.

Use the appropriate security modules on a host where possible. For example, run SELinux in enforcing mode to protect the host from the container images you're running. In addition, when using a volume mount, consider using the -z option if you need to share an SELinux security context between containers or between the container and the host system. This is useful when running a container as a non root user because the container is evaluated with the same SELinux context as the host. To restrict the volume to only the running container, use the -Z option. See Setting Up Container Mounts for more information.

Verify that Podman images are received and deployed unchanged from a source with a trusted reputation and which has been authenticated. For example, see Configuring Podman for Signed Images.

When pulling images from remote sources, ensure that the connection is protected and that you're using HTTPS for the pull request. Don't use insecure image registries that aren't protected by TLS.

Where possible, use Podman images based on a curated, trusted collection of image suppliers.

When using Containerfiles to build new images, review base images, and installed software for security. To help ensure that new images use base images and software that you have reviewed for security vulnerabilities:

• Specify a fixed version in the base image in an image Containerfiles.

• Specify fixed versions in package pulls in the build steps of an image Containerfile (note that dependencies of dependencies can still be a reliability problem).

• Ensure the that package pulls in the build steps are using trusted and verified sources.

Don't install unnecessary packages into new image builds. Review Containerfiles to remove unnecessary installation steps so that images remain limited to their function.

Podman runs each container as the host user running the Podman container. The host user can be the root user or a non root user. For most security, run containers with a non root host user.

Consider limiting container memory and CPU usage using the -m and --memory-swap options for memory and swap memory, and the -c option for CPU.

To prevent potential denial-of-service resulting from a container that spins out of control, limit container restarts using the --restart=on-failure:N option when creating or running a container.

Podman provides facilities to monitor container resource usage, such as memory consumption, CPU time, I/O and network usage. Review container resource usage for performance, error detection, and anomalous behavior. Consider using tools to monitor real-time resource usage for anomalous activity such as use of resources, suspicious traffic, and unexpected user activity.

podman run -v /host_directory_to_be_mounted:/target_container_directory:ro oraclelinux:9

In the previous example, host_directory_to_be_mounted is the host directory and files to be mounted as a volume and target_container_directory is the directory on the container where the host directory is to be mounted.

Don't mount sensitive host system directories at container runtime:

• /

• /boot

• /dev

• /etc

• /lib

• /proc

• /sys

• /usr

Consider using tools that help automate container safety checks and to monitor for changes within containers.

Systematically remove images and containers that aren't needed from the host system to avoid image and container sprawl and to help prevent the accidental usage of an old, unused image or container that has might have avoided security scrutiny. Consider using the Podman auto-update feature to automate the process of checking for new image versions and redeploying impacted containers automatically.

Oracle Linux divides the root user into distinct units, called capabilities. By default, the following kernel capabilities are granted to a container:

• CHOWN

• DAC_OVERRIDE

• FSETID

• FOWNER

• NET_RAW

• SETGID

• SETUID

• SETFCAP

• SETPCAP

• NET_BIND_SERVICE

• SYS_CHROOT

• KILL

By default, the following notable kernel capabilities are removed from a container:

• SYS_TIME

• MKNOD

• NET_ADMIN

• SYS_MODULE

• SYS_NICE

• SYS_ADMIN

• AUDIT_WRITE

Don't use the --privileged option when starting containers because it disables the security features that isolate the container from the host such as dropped capabilities, limited devices, read-only mount points, and volumes and so on.

When creating and running containers, limit kernel resources by using the --ulimit option or set container defaults using the --default-ulimit when starting the Podman service.

If you do run a network for a container, when publishing ports to the host, specify the IP address of the interface that you want the port to bind to so that the attack surface is reduced to the network interface where the container is listening. Podman publishes to all interfaces (0.0.0.0) by default if an IP address isn't specified when using the -p or --publish option.

Don't run SSH inside containers.

Don't map privileged ports (< 1024) inside containers.

Don't use the --net=host mode option for containers when they're started or run. This option gives the container full access to local system services and is insecure.

By default, Podman containers limit the system calls available to containers using the system calls specified in the /usr/share/containers/seccomp.json file. This list is compatible with most containers and you don't need to add more system calls.

Don't share host namespaces such as the PID or IPC namespaces when starting or running containers.

Don't expose host devices into containers when you start or run them.

Because the kernel is shared between containers, kernel calls increase risk to other containers running on the host system. Avoid kernel calls within containerized applications wherever possible.

Ensure that containerized applications run as a non root user. Because the UIDs are shared across the host, the root user in a container is the root user on the host.

Most applications don't need any setuid or setgid binaries. If you can, disable, or remove such binaries. By doing so, you remove the chance of them being used for privilege escalation attacks. If you discover binaries that have setuid or setgid permission flags, remove them altogether, or try to remove the permission flags to remove the risks that are associated with these permissions on a binary.

As much as is possible, design applications to be stateless, rollable, instantly migrateable microservices container apps if possible. If using applications outside of your own design, take this approach into consideration when selecting software that you intend to run within containers. This quality can be helpful in maintaining service during and in the time following a breach or accident in the system.