security_options

Home

Docker Container Security Options

This guide explores some security options available for Docker containers, focusing on Seccomp profiles and dropping capabilities to reduce the attack surface.

(Assumption: Examples may use a custom image named hackon:v1. If this image is not available, you can substitute it with a standard image like ubuntu or alpine and install necessary tools if specific functionality from hackon:v1 is being tested.)

1. Seccomp Security Profiles

Seccomp (Secure Computing mode) is a Linux kernel feature that can restrict the system calls a process is allowed to make. Docker uses seccomp profiles to limit the system calls available to containers, enhancing security.

1.1 Checking Seccomp Support

Verify that your Docker installation and host kernel support Seccomp:

# Check Docker info
docker info | grep -i seccomp

# Alternatively, check your kernel configuration
# This command looks for SECCOMP support in your running kernel's config.
grep SECCOMP /boot/config-$(uname -r)

For more detailed information on Seccomp with Docker, refer to the official Docker documentation.

1.2 Getting Docker's Default Seccomp Profile

Docker comes with a default seccomp profile. You can download it to inspect or modify it.

wget https://raw.githubusercontent.com/moby/moby/master/profiles/seccomp/default.json

This default.json file lists the system calls that are allowed by default.

1.3 Running a Container with the Default Seccomp Profile

By default, Docker containers run with this seccomp profile. You can also specify it explicitly.

docker run --rm -it \
    --security-opt seccomp=@./default.json \
    hackon:v1 bash

(Note: Changed seccomp=default.json to seccomp=@./default.json to explicitly load from file, assuming default.json is in the current directory. If default.json is placed in Docker's seccomp profiles directory, e.g., /var/lib/docker/seccomp/default.json, then seccomp=default.json might work directly, but loading from a local file is more explicit for testing.)

Experiment: Inside the container, try to create a file and change its permissions (e.g., touch test.txt; chmod 000 test.txt). Does it work as expected? (The default profile should allow chmod).

1.4 Customizing and Testing Seccomp Profiles

You can create custom seccomp profiles to further restrict or change allowed syscalls.

1. Download an example custom profile: This example profile (default-no-chmod.json) is designed to be similar to the default profile but disallows the chmod syscall.

   wget https://raw.githubusercontent.com/docker/labs/master/security/seccomp/seccomp-profiles/default-no-chmod.json

2. Run a container with the custom profile:

   docker run --rm -it \
       --security-opt seccomp=@./default-no-chmod.json \
       hackon:v1 bash

   (Again, using seccomp=@./default-no-chmod.json to load from the downloaded file.)

   Experiment: Inside this container, try to create a file and then change its permissions using chmod. What is the result? (The chmod command should fail with an "Operation not permitted" error).

1.5 Unconfined Mode (Disabling Seccomp)

You can run a container without the default seccomp profile by using seccomp=unconfined. This removes seccomp restrictions but increases the attack surface. Use with caution.

# The debian:jessie image is old; consider using a more current Debian or Ubuntu image.
# The 'unshare' command here demonstrates creating a new user namespace, making the user root inside it.
# This is separate from seccomp but shows another way to alter privilege.
docker run --rm -it --security-opt seccomp=unconfined debian:jessie \
    unshare --map-root-user --user sh -c "whoami; id"

(Added a note about debian:jessie being old. Clarified the unshare command's purpose.) Running without seccomp means all syscalls are allowed by seccomp filtering (though other security mechanisms like capabilities still apply).

2. Dropping Capabilities

Linux capabilities divide the privileges traditionally associated with superuser into distinct units. Docker containers run with a default set of capabilities. You can drop capabilities to further restrict a container.

1. Attempt to bind to a privileged port (e.g., port 80) with default capabilities: The NET_BIND_SERVICE capability is typically required to bind to ports below 1024. The default capability set for Docker containers usually includes this.

   # This command might succeed or fail depending on whether the 'hackon:v1' image's
   # default user has permission or if nc tries to drop privileges.
   # If it fails with "Permission denied", it means NET_BIND_SERVICE is needed and possibly not effective for the user.
   # If it succeeds, the default capabilities allowed it.
   docker run --rm -it hackon:v1 nc -v -l -p 80

   (Added -v and -l -p for netcat listening mode.)

2. Attempt to bind after dropping NET_BIND_SERVICE capability:

   # This command should fail to bind to port 80 because the necessary capability is dropped.
   docker run --rm -it --cap-drop NET_BIND_SERVICE hackon:v1 nc -v -l -p 80

   You should see a "Permission denied" error or similar when nc tries to bind to port 80. This demonstrates that dropping the capability successfully restricted this action.

Home