docker build should support option for specifying a custom seccomp profile

[MichaelSimons]

Output of docker version:

Client:
 Version:      1.10.2
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   c3959b1
 Built:        Mon Feb 22 22:37:33 2016
 OS/Arch:      darwin/amd64

Server:
 Version:      1.10.2
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   c3959b1
 Built:        Mon Feb 22 22:37:33 2016
 OS/Arch:      linux/amd64

Output of docker info:

Containers: 1
 Running: 0
 Paused: 0
 Stopped: 1
Images: 3
Server Version: 1.10.2
Storage Driver: aufs
 Root Dir: /mnt/sda1/var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 10
 Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Plugins: 
 Volume: local
 Network: bridge null host
Kernel Version: 4.1.18-boot2docker
Operating System: Boot2Docker 1.10.2 (TCL 6.4.1); master : 611be10 - Mon Feb 22 22:47:06 UTC 2016
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 1.956 GiB
Name: default
ID: IJCF:IXCO:C32D:S3BP:3WRN:VFRE:DKKL:ZOPL:ZJAZ:ORJG:GJSV:K2WC
Debug mode (server): true
 File Descriptors: 10
 Goroutines: 22
 System Time: 2016-03-01T15:34:54.098983226Z
 EventsListeners: 0
 Init SHA1: 
 Init Path: /usr/local/bin/docker
 Docker Root Dir: /mnt/sda1/var/lib/docker
Username: msimons
Registry: https://index.docker.io/v1/
Labels:
 provider=virtualbox

Currently there doesn't seem to be a way to change the seccomp profile used during docker builds. It would be nice if you could specify --security-opt seccomp:<profile path> when building.

Scenario:

FROM microsoft\dotnet

WORKDIR /myapp
# TODO: obtain your dotnet app - pull from SCC or use COPY

# restore the dependencies
RUN dotnet restore

# build and run the app on entry
ENTRYPOINT ["dotnet", "run"]

Building the above Dockerfile will fail because the dotnet CLI tooling relies on the LTTng library which makes a blacklisted syscall. (see #20818)

This feature request was mentioned in #20634 as a possible solution.

[cpuguy83]

The reason I'd be weary of this is we use seccomp to help provide protection for the host. Part of this protection is in place to ensure that builds can't change host properties, thus making a non-portable image.

[justincormack]

I don't think this is a good solution, it is not going to be widely supported in autobuild environments, and will make builds much less portable.

[justincormack]

All the issues with blacklisted syscalls for build that have been raised have been resolved, so I am not sure there is any need for this.

[thaJeztah]

yes, I'll close this one; the direct issue at hand is resolved, and it's unlikely we'll make changes to the profile used during build for the reasons mentioned above