Shulou(Shulou.com)06/02 Report--

Podman uses the traditional fork/exec model (as opposed to the client / server model) to run the container.

Before moving on to the main topics of this article, Podman and containers, I need to know a little bit about the technology of Linux auditing capabilities.

What is audit?

The Linux kernel has an interesting security feature called auditing. It allows administrators to monitor security events on the system and log them to audit.log, which can be stored locally or remotely on another machine to prevent hackers from trying to cover his tracks.

The / etc/shadow file is a security file that needs to be monitored frequently because adding records to it may allow an attacker to gain access to the system. The administrator wants to know if any process has modified the file, and you can do so by executing the following command:

# auditctl-w / etc/shadow

Now let's see what happens when I modify the / etc/shadow file:

# touch / etc/shadow # ausearch-f / etc/shadow-I-ts recenttype=PROCTITLE msg=audit: proctitle=touch / etc/shadow type=SYSCALL msg=audit: arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffff9c a1=0x7ffdb17f6704 a2=O_WRONLY | O_CREAT | O_NOCTTY | O_NONBLOCK a3=0x1b6 items=2 ppid=2712 pid=3727 auid=dwalsh uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=3 comm=touch exe=/usr/bin/touch subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key= (null) `

There was a lot of information in the audit record, but I noticed that it recorded that the root modified the / etc/shadow file, and that the audit UID (auid) for the process was owned by dwalsh.

Has the kernel modified this file?

Tracking login to UID

Log in to UID (loginuid), which is stored in / proc/self/loginuid, which is part of the proc structure of each process on the system. This field can only be set once; once set, the kernel will not allow any process to reset it.

When I log in to the system, the login program sets the loginuid field for my login process.

My (dwalsh) UID is 3267.

$cat / proc/self/loginuid3267

Now, even if I become root, my login UID will remain the same.

$sudo cat / proc/self/loginuid3267

Note that each process that fork and exec from the initial login process automatically inherits loginuid. This is how the kernel knows that the person who logs in is dwalsh.

Container

Now let's take a look at the container.

Sudo podman run fedora cat / proc/self/loginuid3267

Even the container process keeps my loginuid. Now let's try Docker.

Sudo docker run fedora cat / proc/self/loginuid 4294967295

Podman uses the traditional fork/exec model for containers, so the container process is a descendant of the Podman process. Docker uses the client / server model. The docker command I executed is the Docker client tool, which communicates with the Docker daemon through client / server operations. The Docker daemon then creates the container and handles the communication between stdin/stdout and the Docker client tool.

The default loginuid for a process (before setting loginuid) is 4294967295. Because the container is the descendant of the Docker daemon and the Docker daemon is the descendant of the init system, we see that the systemd, the Docker daemon and the container process all have the same loginuid:4294967295, and the audit system regards it as having no audit UID set.

Why is cat / proc/1/loginuid 4294967295 different?

Let's see what happens if the container process started by Docker modifies the / etc/shadow file.

$sudo docker run-- privileged-v /: / host fedora touch / host/etc/shadow $sudo ausearch-f / etc/shadow-I type=PROCTITLE msg=audit: proctitle=/usr/bin/coreutils-coreutils-prog-shebang=touch / usr/bin/touch / host/etc/shadow type=SYSCALL msg=audit: arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffff9c a1=0x7ffdb6973f50 a2=O_WRONLY | O_CREAT | O_NOCTTY | O_NONBLOCK a3=0x1b6 items=2 ppid=11863 pid=11882 Auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty= (none) ses=unset comm=touch exe=/usr/bin/coreutils subj=system_u:system_r:spc_t:s0 key= (null)

In the Docker case, the auid is not set (4294967295); this means that the security personnel may know that a process has modified the / etc/shadow file but the identity is lost.

If the attacker then deletes the Docker container, there will be no tracking information on who modifies the / etc/shadow file on the system.

How could it be abused?

Now let's take a look at the same scenario under Podman.

$sudo podman run-- privileged-v /: / host fedora touch / host/etc/shadow $sudo ausearch-f / etc/shadow-I type=PROCTITLE msg=audit: proctitle=/usr/bin/coreutils-- coreutils-prog-shebang=touch / usr/bin/touch / host/etc/shadow type=SYSCALL msg=audit): arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffff9c a1=0x7fffdffd0f34 a2=O_WRONLY | O_CREAT | O_NOCTTY | O_NONBLOCK a3=0x1b6 items=2 ppid=11671 pid=11683 Auid=dwalsh uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty= (none) ses=3 comm=touch exe=/usr/bin/coreutils subj=unconfined_u:system_r:spc_t:s0 key= (null)

Because it uses the traditional fork/exec approach, Podman records everything correctly.

This is just a simple example of observing the / etc/shadow file, but the audit system is useful for observing processes on the system. Using the fork/exec container runtime (instead of the client / server container runtime) to start the container allows you to maintain better security by auditing logging.

The last thought

When starting the container, the fork/exec model has many other good features compared to the client / server model. For example, systemd features include:

SD_NOTIFY: if the Podman command is put into the systemd unit file, the container process can return a notification via Podman indicating that the service is ready to receive the task. This is something that cannot be done in client / server mode.

Socket activation: you can pass connected sockets from systemd to Podman and to the container process for use. This is not possible in the client / server model.

In my opinion, its best function is to run Podman and containers as non-root users. This means that you will never grant the user root permission on the host, and in the client / server model (as used by Docker), you must open the socket of the privileged daemon running as root to start the container. There, you will be dominated by the security mechanisms implemented in the daemon and the host operating system-a dangerous proposition.

Original link: https://www.linuxprobe.com/podman-docker.html

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.