Cannot run sysctl command in Dockerfile

Question

I'm trying to make my first dockerfile(I'm new to this), and I need the system to run the command sysctl -w kernel.randomize_va_space=0 (its an lab env.), but I get the error:

sysctl: setting key "kernel.randomize_va_space": Read-only file system

Whenever I try to build the dockerfile, any suggestion how to get this around ?

FROM avatao/lesp:ubuntu-14.04

USER root

COPY ./solvable/ /

RUN sysctl -w kernel.randomize_va_space=0

VOLUME ["/tmp"]

EXPOSE 2222

WORKDIR /home/user/

USER user

CMD ["/usr/sbin/sshd", "-Df", "/etc/ssh/sshd_config_user"]

Preter

Do you need it during building the image or when the image runs? – Schweiz

when the image runs – Preter

You can try the sysarch approach. But not from RUN, RUN is executed at build time. – Schweiz

Answer 1

Since Docker containers share the host system's kernel and its settings, a Docker container usually can't run sysctl at all. (You especially can't disable security-critical settings like this one.) You can set a limited number of sysctls on a container-local basis with docker run --sysctl, but the one you mention isn't one of these.

Furthermore, you also can't force changes like this in a Dockerfile. A Docker image only contains a filesystem and some associated metadata, and not any running processes or host-system settings. Even if this RUN sysctl worked, if you rebooted your system and then launched a container from the image, that setting would be lost.

Given what you've shown in this Dockerfile – customized Linux kernel settings, no specific application running, an open-ended ssh daemon as the container process – you might consider whether a virtual machine fits your needs better. You can use a tool like Packer to reproducibly build a VM image in much the same way a Dockerfile builds a Docker image. Since a VM does have an isolated kernel, you can run that sysctl command there and it will work, maybe via normal full-Linux-installation methods like an /etc/sysctl.conf file.

Midnight

Are you sure Docker containers share the host system's kernel and its settings? I set net.core.somaxconn to 65535 on host, however, the container created on the same host still shows 128 for net.core.somaxconn. – Karie

The docker run documentation (I fixed the link in my answer) notes that net.* sysctls are namespaced, and so they can be set on a per-container basis. – Midnight

Answer 2

This is expected since docker restricts access to /proc and /sys (for security). Fundamentally, in order to achieve what you are trying, you need to either give the user CAP_SYS_ADMIN or run in privileged mode, neither of which is allowed during build, see {issue}.

Currently, if you can have those things run after the container is running, then you can use either --cap-add=SYS_ADMIN or --privileged flag. Ideally, these aren't things we would do in a production system, but you seem to be running in a lab setup. If doing it at the run stage, I would recommend first trying the --sysctl flag, but that only supports a subset of command and I'm not sure if it will let you modify kernel settings.

Breadnut

yeah it's a lab setup(trying to make a setup which the students can connect via ssh and perform the "return to libc" attack). are those flags needs to be added when u build the docker? (docker build .... --privileged?) – Preter

@Preter unfortunately, the github issue to add privileged type support to docker build is still open (open for 6 years) - you can follow along in issues/1916 – Breadnut

The issue has been closed. However as mentioned by @David Maze, net.* sysctls can only be used on a container-basis, not for images. – Bluing

Answer 3

Run your container using the following:

docker run --rm -it --privileged myapp:1.0 /bin/bash

Then you will be able to execute your Dockerfile without any problem.

Sherikasherill

If you do this, understand it gives the container all capabilities and lifts restrictions enforced by the cgroup controller. It's better to follow the principle of least privilege and use --cap-add to give only those capabilities needed. See also https://mcmap.net/q/152219/-privileged-containers-and-capabilities. – Bereft