Twistlock provides app-aware system call defense, which observes the app in your container, and takes action when abnormal system calls are detected. During learning mode, Twistlock matches the app in the container with the relevant syscall profile. Then, every time a container is instantiated, Defender automatically injects the proper syscall profile into the container.
Twistlock Labs has curated a library of profiles that define the minimum set of syscalls required for common containerized apps, such as Mongo, MySQL, Redis, Nginx, and others. For all other apps, Twistlock injects a generic, broadly applicable policy.
Twistlock syscall defense is built on seccomp. Seccomp is a filter that reduces the kernel’s surface to userland processes, including containers, by restricting access to system calls. Custom filters, also known as profiles, can be individually applied to containers. Docker curates a default seccomp profile, which is moderately protective, while providing wide application compatability.
By default, all containers use the Docker default seccomp profile. If Twistlock detects that the container is a covered app, such as MongoDB, the container is started with one of Twistlock’s curated, more restrictive, app-specific profiles instead.
Twistlock raises an alert when a container makes a system call not whitelisted by the profile. This default behavior is the result of the Default - alert on suspicious runtime behavior rule, which you can find in Defend > Runtime > Container Policy. You can further customize the baseline profiles by installing new runtime rules, and whitelisting or blacklisting specific system calls.
The scope for the syscall profile is the entire container, not just individual processes inside the container. The syscall profile does not change dynamically; there is no learning period. You can view details about the installed profile in the image’s runtime model. Go to Monitor > Runtime > Container Models, click on a model, then select the System Calls tab.
Updates to our library of curated syscall profiles is distributed via the Intelligence Stream.
The following diagram illustrates the basic flow when a container is started:
The operator starts a container.
Defender intercepts the command.
Defenders starts the container, injecting a seccomp profile into the container. The profile is constructed from:
Either a Twistlock-curated app-specific profile or the Docker default seccomp profile, plus
Any system calls required by any capabilities enabled for the container, plus
Any system calls whitelisted in an applicable container runtime rule, minus
Any system calls blacklisted in an applicable container runtime rule.
Syscall defense has a number of minimum requirements:
Docker 1.10 or later.
seccomp 2.2.1 or later. This version of seccomp is available on Debian 9, Ubuntu 16.04, Fedora 22, CentOS 7, RHEL 7 and Oracle Linux 7.
Linux kernel version 3.17 or later (required for seccomp support).
If these minimum requirements are not met, Defender emits an error message to the log file. Syscall defense is not supported on Docker Swarm.
By default, syscall defense is enabled and set to Alert with the Default - alert on suspicious runtime behavior rule under Defend > Runtime > Container Policy. The supported actions are Disable, Alert, Prevent, and Block, where:
Disables syscall protection.
(Default) Raises alerts when the seccomp policy is violated.
Defender stops the syscall that violates your seccomp policy. You can specify additional whitelist and blacklist system calls to augment the seccomp profile that Twistlock injects into your container.
Stops the container when the seccomp policy is violated. You can specify additional whitelist and blacklist system calls to augment the seccomp profile that Twistlock injects into your container.
Create a runtime rule that blocks the recvfrom() system call, which is used by ping. Then start a container, and try running ping inside it.
Open Console.
Go to Defend > Runtime > Container Policy.
Click Add rule.
Select the General tab:
In Rule name, enter a string.
Apply this rule to a specific resource. In Images, enter alpine* to filter on all versions of alpine.
Select the System Calls tab.
In Effect, select Prevent.
In Explicitly denied system calls, enter recvfrom.
Click Save.
Run the container.
$ docker run -it alpine
Inside the container, run ping, which calls recvfrom.
# ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes Bad system call
Verify an audit was recorded. Go to Monitor > Events > Container Audits.