Runtime defense for system calls
Prisma Cloud 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, Prisma Cloud 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.
Prisma Cloud 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, Prisma Cloud injects a generic, broadly applicable policy.
Prisma Cloud 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 Prisma Cloud detects that the container is a covered app, such as MongoDB, the container is started with one of Prisma Cloud’s curated, more restrictive, app-specific profiles instead.
Prisma Cloud 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 Prisma Cloud-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.
System requirements
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.
Rule options
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:- Disable--Disables syscall protection.
- Alert--(Default) Raises alerts when the seccomp policy is violated.
- Prevent--Defender stops the syscall that violates your seccomp policy. You can specify additional whitelist and blacklist system calls to augment the seccomp profile that Prisma Cloud injects into your container.
- Block--Stops the container when the seccomp policy is violated. You can specify additional whitelist and blacklist system calls to augment the seccomp profile that Prisma Cloud injects into your container.
Testing runtime defense for syscalls
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 toDefend > Runtime > Container Policy.
- ClickAdd rule.
- Select theGeneraltab:
- InRule name, enter a string.
- Apply this rule to a specific resource. InImages, enter alpine* to filter on all versions of alpine.
- Select theSystem Callstab.
- InEffect, selectPrevent.
- InExplicitly denied system calls, enterrecvfrom.
- ClickSave.
- Run the container.$ docker run -it alpineInside 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 callVerify an audit was recorded. Go toMonitor > Events > Container Audits.
