End-of-Life (EoL)

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
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:
  1. The operator starts a container.
  2. Defender intercepts the command.
  3. 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,
    • Any system calls required by any capabilities enabled for the container,
    • Any system calls whitelisted in an applicable container runtime rule,
    • 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
with the
Default - alert on suspicious runtime behavior
rule under
Defend > Runtime > Container Policy
. The supported actions are
, and
, 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.
  1. Open Console.
  2. Go to
    Defend > Runtime > Container Policy
  3. Click
    Add rule
  4. Select the
    1. In
      Rule name
      , enter a string.
    2. Apply this rule to a specific resource. In
      , enter alpine* to filter on all versions of alpine.
  5. Select the
    System Calls
    1. In
      , select
    2. In
      Explicitly denied system calls
      , enter
  6. Click
  7. Run the container.
    $ docker run -it alpine
  8. Inside the container, run ping, which calls recvfrom.
    # ping PING ( 56 data bytes Bad system call
  9. Verify an audit was recorded. Go to
    Monitor > Events > Container Audits

Recommended For You