25

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"]
Corey
  • 1,217
  • 3
  • 22
  • 39
neorus
  • 477
  • 1
  • 6
  • 19

3 Answers3

28

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.

David Maze
  • 130,717
  • 29
  • 175
  • 215
  • 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. – xiao su Nov 22 '19 at 02:11
  • 1
    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. – David Maze Nov 22 '19 at 02:38
7

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.

Debosmit Ray
  • 5,228
  • 2
  • 27
  • 43
  • 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?) – neorus Feb 23 '19 at 19:32
  • @neorus 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](https://github.com/moby/moby/issues/1916) – Debosmit Ray Feb 23 '19 at 19:37
  • The issue has been closed. However as mentioned by @David Maze, `net.*` sysctls can only be used on a container-basis, not for images. – schlumpfpirat Apr 13 '21 at 11:11
0

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.

Abdulla Nilam
  • 36,589
  • 17
  • 64
  • 85
ahmed elouadrhiri
  • 1
  • _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://stackoverflow.com/a/36441605/2908724. – bishop Apr 12 '23 at 20:20