To strengthen the Docker container: Disable the SUID program

Docker's security issue has always been a hot topic of concern, this article focuses on the creation of SUID procedures brought about by the security risks, put forward the corresponding solution, so as to strengthen the Docker security, worth reading.

Most people think about strengthening the Docker container, the first thought is to set the default user to a non-root account. Before the hacker attacks the container, they need to get the root privileges of the container. Running a container with a non-root account will make the attack more difficult.

When running the docker run or docker create command, the -u or -user parameter can be used to start a container with a non-root user that already exists in the target image. You can use the docker history view the container command history, in which to find adduser command, so you can find the existing user. You can view the USER command to determine whether the default user is set. Or, directly from the mirror to start a container and enter the shell command line directly manual check. If you do not like to check to check, you can usually use the "nobody" users.

I think Tutum recently does not provide a specific interface to help view the users who are running in the container. So if you want to run as a non-root user, you must make sure that the default user setting you want to start the mirror service becomes this non-root user.

Running with a non-root user is a good start, but you can do it better. One of the interesting things is to cancel the file SUID parameter settings, or directly from the mirror to delete the file with this parameter. Now you may ask: "What is the SUID parameter?"

The SUID parameter refers to Linux file permissions. Most Linux users have a certain understanding of Linux file permissions. The more well-known 9 parameters describe the permissions that file owners, groups, and other users have on a particular file. such as:

  "-rwxr-xr-x 1 root root" (or 755) 

  • The file owner can read, write and execute the file
  • Users in the filegroup can read and execute the file
  • Any other user can read and execute the file

The SUID parameter is a refinement of the executable parameters. It tells Linux to set the active group or user to the owning group or user of the file when executing the file.

  "-rwsr-xr-x 1 root root" 

or

  "-rwxr-sr-x 1 root root" 

Often ordinary users need to access a program that requires specific permissions to access. The most common ping command. I like this example because it is sometimes very insignificant and harmless. ping requires root privileges because it uses the ICMP protocol. A typical Linux installation will include multiple such tools. There are 22 programs with the SUID setting in the ubuntu: latest image.

  / Sbin / unix_chkpwd 
/ Usr / bin / chage
/ Usr / bin / passwd
/ Usr / bin / mail-touchlock
/ Usr / bin / mail-unlock
/ Usr / bin / gpasswd
/ Usr / bin / crontab
/ Usr / bin / chfn
/ Usr / bin / newgrp
/ Usr / bin / sudo
/ Usr / bin / wall
/ Usr / bin / mail-lock
/ Usr / bin / expiry
/ Usr / bin / dotlockfile
/ Usr / bin / chsh
/ Usr / lib / eject / dmcrypt-get-device
/ Usr / lib / pt_chown
/ Bin / ping6
/ Bin / su
/ Bin / ping
/ Bin / umount
/ Bin / mount

The following example shows how the SUID parameter works. There are the following Dockerfile:

  FROM ubuntu: latest 

RUN chmod u + s / usr / bin / whoami

RUN adduser --system --no-create-home --disabled-password --disabled-login --shell / bin / sh example

USER example

CMD printf "Container running as:% s \ n" `id -u -n` && printf" effectively running whoami as:% s \ n "` whoami`

Building and running the mirror from this Dockerfile will get the following output:

  Docker build -t tutumblog / suid_whoami. \ 
&& docker run --rm tutumblog / suid_whoami

...

Container running as: example
Effectively running whoami as: root

In this example, I start from the underlying Ubuntu image, set the whoami command to the SUID parameter. Then add the example user for this mirror and set it as the default user for the container created from this mirror. The problem can be seen is that two different current users are shown. When the example user executes whoami , because it has a SUID parameter setting, Linux executes it with the root user, so the owner of the display file is root.

It is now clear that whoami is not a program that needs to be executed by its owner. In fact it shows the wrong result. The question that needs to be solved now is: "Do I need a program with a SUID setup at runtime?" I think most of the time the answer is: "No."

I know you can find some examples of procedures that require runtime setup with SUID parameters. Some people need crontab . Some people need to ping to diagnose the problem. But what if some of the 22 programs have a bug? If the program sets the SUID parameter and the hacker detects the bug, they will control the entire container.

Cancel the SUID parameter settings can solve this problem. Consider adding a row to the Dockerfile to cancel the setup of all SUID parameters in the mirror. The following example:

  FROM ubuntu: latest 

RUN adduser --system --no-create-home --disabled-password --disabled-login --shell / bin / sh example

RUN for i in `find / -perm +6000 -type f`; do chmod as $ i; done

USER example

CMD / bin / bash

Or, you can delete these programs directly to solve the problem:

  ... 
RUN for i in `find / -perm +6000 -type f`; do rm -f $ i; done
...

Containers are used to isolate rather than virtualize. Based on this, Docker mirroring is used to provide the smallest set of files required for an application or service to start. If you really need some of these programs to run as root, you can choose which containers need to be enhanced and which containers are not needed. But to be aware of the risks that exist.

Original links: Hardening Docker Containers: Disable SUID Programs (translation: Cui Jingwen)

===========================
Translator introduction <br /> Cui Jingwen, now working for VMware, senior software engineer, responsible for desktop virtualization products, quality assurance work. Worked for years in the IBM WebSphere Business Process Management software. On the virtualization, middleware technology has a strong interest.

Heads up! This alert needs your attention, but it's not super important.