3

To make use of SGX enclaves applications have to talk to the SGX driver which is exposed via /dev/isgx on the host. We execute such applications inside of Docker containers mapping /dev/isgx inside with the --device command line option.

Is there an option to add a device (/dev/isgx in this case) to any container ever started by a docker engine?

Edit:

Progress on my side so far:

Docker uses containerd & runc to create a containers configuration before it is started. Docker's configuration file /etc/docker/daemon.json has a field runtimes where one can provide arbitrary arguments to runc:

[...]    
"runtimes": {
    "runc": {
        "path": "runc"
    },
    "custom": {
        "path": "/usr/local/bin/my-runc-replacement",
        "runtimeArgs": [
            "--debug"
        ]
    }
},
[...]

Sadly, it seams runc is not consuming to many useful arguments for my means (runc --help and runc spec --help <-- creates the configuration).

I found interesting source code regarding DefaultSimpleDevices and DefaultAllowedDevices in runc's codebase. The last commit to this file says 'Do not create /dev/fuse by default' which is promising, but would involve building my own runc. I was hoping for a generic solution via a configuration option.

fzgregor
  • 1,807
  • 14
  • 20

2 Answers2

2

UPDATE

This is not the correct answer. Turns out, that docker's default parent cgroup already has open devices permissions:

/# cat /sys/fs/cgroup/devices/docker/devices.list 
a *:* rwm

Upon container creation a new cgroup for that container is created with more restricted devices rules.

ORIGINAL ANSWER

I think you could use cgroups to achieve what you want. You could create a new cgroup on your host machine which allows access to /dev/isgx and start your docker daemon with --cgroup-parent=<my-cgroup-name>. You could also set the cgroup-parent option in your /etc/docker/daemon.json.

If you have never worked with cgroups before, then it might not be trivial to setup though. How to create a new cgroup depends on your host system, but you must use the devices controller to whitelist specific devices for a cgroup.

E.g., one way is to use libcgroup's /etc/cgconfig.conf and give read/write access to a block device for cgroup dockerdaemon in the following way:

group dockerdaemon {
  devices {
    devices.allow = b <device-major>:<device-minor> rw
  }
}

Here is one example on how to find out the major/minor of your block device:

sudo udevadm info -n /dev/isgx

Here are some further links that might give you more insights into the whole cgroup topic:

fishi0x01
  • 3,579
  • 21
  • 25
  • Thanks, you are right, I have not yet worked with cgroups. I'll give it a shot. – fzgregor Feb 07 '17 at 12:32
  • 2
    After looking into it I doubt cgroups can help here. It seams the docker daemon is by default running with the most permissive device cgroup there is. Only when it starts a container a new restricted cgroup is created for it. In fact `--device /dev/X` adds the devices major and minor number to the cgroup. – fzgregor Feb 07 '17 at 13:29
  • @fzgregor you are absolutely right. I assumed that new cgroups would inherit **ALL** the settings from its parent, but I was wrong. Thank you for the clarification! I updated the answer with your findings. – fishi0x01 Feb 07 '17 at 15:54
0

You need something like this in your docker-compose.yaml file (or similar for other Docker-based technologies:

    devices:
      - "/dev/isgx:/dev/isgx"
Dan Anderson
  • 2,265
  • 1
  • 9
  • 20