When Gremlin runs within a container,
gremlin processes run as
root. This is because there are several file resources that Gremlin must mount from the host which are owned by
root on the host machine:
/var/log/gremlin: These are mounted from the host into the Gremlin agent container and sidecar attacks. By default, container runtimes will set the ownership of these resources to
- Container runtime sockets (e.g.
/var/run/docker.sock), which by default will be owned by
Though Gremlin runs as
root within the container in which it runs, Gremlin is restricted by the specific capabilities it requests, despite running as
root. Here are some other mitigations system administrators can make to reduce the impact of Gremlin’s usage of
- While Docker’s default seccomp profile is already fairly restrictive, you can remove any undesired syscalls by overriding this default, or provide a more restrictive seccomp profile to Gremlin containers.
- Avoid running Gremlin within the network or process namespace of the host. For Docker, avoid
docker run --net=host --pid=host). Note that this will disable Gremlin’s ability to run host-level Network and Process Killer attacks.
- Consider an extra layer of safety by enabling AppArmor, SELinux, GRSEC to harden all containers running on your systems
If you do not wish to run Gremlin as a
root user, even with the restrictions described above, consider installing Gremlin directly onto the host where it runs under a dedicated Linux user: