Docker Community Forums

Share and learn in the Docker community.

Security implications of `--cap-add=SYS_PTRACE --security-opt seccomp=unconfined`? (needed for rr)

docker
(Janx) #1

Dear Docker community,

We run a web service that provides developers with pre-configured Docker containers (to develop open source projects like Firefox, Chromium, Thunderbird, Servo and more).

Some developers want to use advanced debugging tools like rr in our containers, but sometimes these don’t work by default.

rr's Docker instructions suggest the following:

simply start your container with the additional arguments --cap-add=SYS_PTRACE --security-opt seccomp=unconfined. You should be aware of the security implications of these flags before using them.

What are the security implications of adding CAP_SYS_PTRACE and seccomp=unconfined to all Docker containers, on shared infrastructure?

EDIT: Specifically, I’d like to understand what kind of havoc users could wreak with these additional capabilities: Could they break out of their containers? Spy on other containers? Execute arbitrary commands on the host? Etc.

(Janx) #2

(FYI the web service is janitor.technology, but for some reason I couldn’t add two links in my post.)

(Janx) #3

Yesterday I had a brief chat with a friend who knows more about this than I do.

He seemed to think that CAP_SYS_PTRACE would allow container users to trace syscalls from their own processes, but not from host processes or from processes in other containers (even if users can sudo in their containers).

He didn’t know about seccomp, or what users could do with the additional syscalls that would be authorized when disabling it.

(Janx) #4

See also: https://github.com/JanitorTechnology/janitor/pull/315

TL;DR: This doesn’t really answer the question, but maybe we don’t need to use seccomp=unconfined to enable rr support after all. Enabling just the syscalls ptrace and perf_event_open should be enough (in combination with adding CAP_SYS_PTRACE).

As you can see in the list of blocked syscalls, the security implications of enabling just ptrace and perf_event_open seem to be “only” leaking host information, whereas enabling all syscalls with an unconfined seccomp sounds a lot more dangerous.