Default seccomp profile blocks personality(...|ADDR_NO_RANDOMIZE)

The default seccomp profile is blocking personality(PER_LINUX|ADDR_NO_RANDOMIZE):

% sudo -g docker docker run --rm -ti debian bash

root@4c48e40eadb3:/# apt update && apt install -y strace
[... SNIP ...]

root@4c48e40eadb3:/# strace -e personality setarch `uname -m` -R /bin/bash
personality(PER_LINUX|ADDR_NO_RANDOMIZE) = -1 EPERM (Operation not permitted)
personality(PER_LINUX|ADDR_NO_RANDOMIZE) = -1 EPERM (Operation not permitted)
setarch: failed to set personality to x86_64: Operation not permitted
+++ exited with 1 +++

(As an aside, it's also blocking personality(PER_LINUX32|ADDR_NO_RANDOMIZE) which is the equivalent for x86 processes)

This is preventing the use of gdb with its ASLR-disabling behaviour (which allows for more deterministic debugging):

root@4c48e40eadb3:/# apt install -y gdb
[... SNIP ...]

root@4c48e40eadb3:/# gdb $(which cat)
[... SNIP ...]

(gdb) r
Starting program: /bin/cat
warning: Error disabling address space randomization: Operation not permitted

[... SNIP - exit out of gdb ...]

root@4c48e40eadb3:/# strace -e personality gdb $(which cat)
[... SNIP ...]
(gdb) r
Starting program: /bin/cat
personality(0xffffffff)                 = 0 (PER_LINUX)
personality(PER_LINUX|ADDR_NO_RANDOMIZE) = -1 EPERM (Operation not permitted)
warning: Error disabling address space randomization: Operation not permitted

This was discussed in #22801 in the context of this breaking the building of emacs. The resolution was to wait for emacs to be buildable with ASLR enabled, and the issue was closed.

On that issue, it was said that:

It is using personality(0x40008) which is ADDR_NO_RANDOMIZE | PER_LINUX32 which disables ASLR (and forces 32 bit). I am not sure about allowing this though, it means anyone can just disable ASLR, which significantly reduces security.

I'm not sure this is the full story, and I think it should be revisited.

My understanding is that the "anyone" who can disable ASLR is someone who's already within the container and does personality() to disable ASLR of the calling process and its child processes. The only ASLR that is disabled is for the process that does personality() and its children. It doesn't affect anything outside the container.

Furthermore it seems as though the effects are reversed when doing suid/sgid (https://github.com/torvalds/linux/blob/5147da902e0dd162c6254a61e4c57f21b60a9b1c/include/uapi/linux/personality.h#L27-L34)

% personality setarch `uname -m` -R /bin/bash

$ cat /proc/self/maps | grep cat | sha1sum
25947c3fa9e641aab4bd0e2c35e56d3d80bdb8f1  -

$ cat /proc/self/maps | grep cat | sha1sum
25947c3fa9e641aab4bd0e2c35e56d3d80bdb8f1  -

(ASLR is disabled when cat is run ordinarily)

vs.

% personality setarch `uname -m` -R /bin/bash

$ sudo cat /proc/self/maps | grep cat | sha1sum
92a1f335686a52a9026ffe26faf3cc98c316e935  -

$ sudo cat /proc/self/maps | grep cat | sha1sum
01155bf3f1cadc25d9709d4654d057f967256512  -

(ASLR is enabled when cat is run under sudo)

If an attacker is already in the container and can call personality(), it doesn't win them anything. I don't see how it gets them any closer to a privesc within the container (as above, the effects are reversed when doing suid/sgid) and I don't see how it gets them any closer to a container escape.

A program that does personality() might do so for good reason (e.g. in the case of gdb trying to disable ASLR on the process being run, to allow for more deterministic debugging). It might also do so for bad reason, and make security worse for itself with respect to remote attackers who aren't already in the container. In such a bad case, it's a bug in the software that calls personality(), and I'm not convinced that the default seccomp profile should be saying "I'm going to stop you doing that for your own good".

If there is indeed a security risk to the host in allowing a process to disable its (and its non-privileged childrens') ASLR, then personality(...|ADDR_NO_RANDOMIZE) should stay blocked. However, if there's no risk to the host in allowing it, I think it should be permitted by the default seccomp profile.