Starting with v1.10, Docker implements a global default seccomp profile that's inherited by every started container. This profile disables one or more kernel calls needed by the initial container process, sshd in this instance, to start chrome's controlling browser process with the ability to issue the system calls essential to construct the chrome sandbox. At this time, I don't precisely know the kernel calls issued by chrome's browser process that are prohibited by Docker, however, the docker run command implements an option permitting root container processes (process having no container process as an ancestor), like sshd, to issue any kernel command. Simply specify the option --security-opt=seccomp:unconfined.
docker run -d --security-opt=seccomp:unconfined -p 127.0.0.1:2222:22 chrome
Since enabling all kernel calls probably results in a more constrained chrome sandbox, as compared to the sandboxing offered by Docker's default container security when running chrome with the --no-sandbox option, starting the container with the unconfined seccomp value likely offers more security until a minimum seccomp profile can be discerned for the root container process that will allow the browser process to successfully construct chrome's sandbox.
Update: 8/2/2016:
Jess Frazelle provides a similar Docker Chrome solution which has been recently transitioned to runc. It seems both her solutions required tweaking to accommodate seccomp enforcement. She created a custom seccomp profile for Chrome which also passes the smoke test when used to run your (jlund's) docker-chrome-pulseaudio image. Assuming the custom seccomp profile was copied to: /etc/seccomp/chrome.json, the docker run command would be encoded as:
docker run -d --security-opt 'seccomp=/etc/seccomp/chrome.json' -p 127.0.0.1:2222:22 chrome
Please note the link to the custom seccomp profile refers to a repository's master branch, therefore, its contents can change potentially rendering it inapplicable for arbitrary configurations/versions of Docker, kernel, and host distributions.
Starting with v1.10, Docker implements a global default seccomp profile that's inherited by every started container. This profile disables one or more kernel calls needed by the initial container process, sshd in this instance, to start chrome's controlling browser process with the ability to issue the system calls essential to construct the chrome sandbox. At this time, I don't precisely know the kernel calls issued by chrome's browser process that are prohibited by Docker, however, the docker run command implements an option permitting root container processes (process having no container process as an ancestor), like sshd, to issue any kernel command. Simply specify the option
--security-opt=seccomp:unconfined.docker run -d --security-opt=seccomp:unconfined -p 127.0.0.1:2222:22 chromeSince enabling all kernel calls probably results in a more constrained chrome sandbox, as compared to the sandboxing offered by Docker's default container security when running chrome with the --no-sandbox option, starting the container with the unconfined seccomp value likely offers more security until a minimum seccomp profile can be discerned for the root container process that will allow the browser process to successfully construct chrome's sandbox.
Update: 8/2/2016:
Jess Frazelle provides a similar Docker Chrome solution which has been recently transitioned to runc. It seems both her solutions required tweaking to accommodate seccomp enforcement. She created a custom seccomp profile for Chrome which also passes the smoke test when used to run your (jlund's) docker-chrome-pulseaudio image. Assuming the custom seccomp profile was copied to:
/etc/seccomp/chrome.json, the docker run command would be encoded as:docker run -d --security-opt 'seccomp=/etc/seccomp/chrome.json' -p 127.0.0.1:2222:22 chromePlease note the link to the custom seccomp profile refers to a repository's master branch, therefore, its contents can change potentially rendering it inapplicable for arbitrary configurations/versions of Docker, kernel, and host distributions.