How to disable linux space randomization via dockerfile?

Question

I'm trying to disable randomization via Dockerfile:

RUN sudo echo 0 | sudo tee /proc/sys/kernel/randomize_va_space

but I get

Step 9 : RUN sudo echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
 ---> Running in 0f69e9ac1b6e
[91mtee: /proc/sys/kernel/randomize_va_space: Read-only file system

any way to work around this? (I see its saying read-only file system any way to get around this?) If its something which the kernel does this means it's outside of my container scope, in that case how am i supposed to work with gdb inside my container? please note this is my target to work with gdb in a container because i'm experimenting with it, so i wanted a container which encapsulates gcc and gdb which i'll use for experimentations.

Answer 1

In host run:

sudo echo 0 | sudo tee /proc/sys/kernel/randomize_va_space

not in docker

Answer 2

Docker has syntax for modifying some of the sysctls (not via dockerfile though) and kernel.randomize_va_space does not seem to be one of them.

Since you've said you're interested in running gcc/gdb you could disable ASLR only for these binaries with:

setarch `uname -m` -R /path/to/gcc/gdb

Also see other answers in this question.

Answer 3

Sounds like you are building a container for development on your own computer. Unlike production environment, you could (and probably should) opt for a privileged container. In a privileged container sysfs is mounted read-write, so you can control kernel parameters as you would on the host. This is an example of Amazon Linux container I use to develop for on my Debian desktop, which shows the difference

$ docker run --rm -it amazonlinux
bash-4.2# grep ^sysfs /etc/mtab
sysfs /sys sysfs ro,nosuid,nodev,noexec,relatime 0 0
bash-4.2# exit
$ docker run --rm -it --privileged amazonlinux
bash-4.2# grep ^sysfs /etc/mtab
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
bash-4.2# exit
$

Notice ro mount in the unprivileged, rw in the privileged case.

---

Note that the Dockerfile command

RUN sudo echo 0 | sudo tee /proc/sys/kernel/randomize_va_space

makes no sense. It will be executed (a) during container build time (b) on the machine where you build the image. You want (a) happen at container's run time and (b) on the machine where you run the container. If you need to change sysctls on image start, write a script which does all the setup and then drops you into the interactive shell, like placing a script into e.g. /root and setting it as the ENTRYPOINT

#!/bin/sh
sudo sysctl kernel.randomize_va_space=0
exec /bin/bash -l

(Assuming you mount host working directory into /home/jas that's a good practice, as bash will read your startup files etc).

You need to make sure you have the same UID and GID inside the container, and can do sudo. How you enable sudo depends on a distro. In Debian, members of the sudo group have unrestricted sudo access, while on Amazon Linux (and, IIRC, other RedHat-like system, the group wheel has. Usually this boils down to an unwieldy run command that you rather want to script than type, like

docker run -it -v $HOME:$HOME -w $HOME -u $(id -u):$(id -g) --group-add wheel amazonlinux-devenv

Since your primary UID and GID match the host, files in mounted host directories won't end up owned by root. An alternative is create a bona fide user for yourself during image build (i.e., in the Dockerfile), but I find this more error-prone, because I can end up running this devenv image where my username has a different UID, and that will cause problems. The use of id(1) in a startup command guarantees UID match.