This functionality is in beta and is subject to change. The design and code is less mature than official GA features and is being provided as-is with no warranties. Beta features are not subject to the support SLA of official GA features.
On Linux 3.17 and later, Journalbeat can take advantage of secure computing mode, also known as seccomp. Seccomp restricts the system calls that a process can issue. Specifically Journalbeat can load a seccomp BPF filter at process start-up that drops the privileges to invoke specific system calls. Once a filter is loaded by the process it cannot be removed.
The kernel exposes a large number of system calls that are not used by Journalbeat. By installing a seccomp filter, you can limit the total kernel surface exposed to Journalbeat (principle of least privilege). This minimizes the impact of unknown vulnerabilities that might be found in the process.
The filter is expressed as a Berkeley Packet Filter (BPF) program. The BPF program is generated based on a policy defined by Journalbeat. The policy can be customized through configuration as well.
A seccomp policy is architecture specific due to the fact that system calls vary by architecture. Journalbeat includes a whitelist seccomp policy for the amd64 and 386 architectures. You can view those policies here.
Seccomp Policy Configurationedit
The seccomp policy can be customized through the configuration policy. This is
an example blacklist policy that prohibits
If the system call being invoked by the process does not match one of the names below then it will be allowed.
If the system call being invoked matches one of the names below then an error will be returned to caller. This is known as a blacklist policy.
These are system calls being prohibited.
These are the configuration options for a seccomp policy.
On Linux, this option is enabled by default. To disable seccomp
filter loading, set this option to
- The default action to take when none of the defined system calls match. See action for the full list of values. This is required.
Each object in this list must contain an
actionand a list of system call
names. The list must contain at least one item.
- A list of system call names. The system call name must exist for the runtime architecture, otherwise an error will be logged and the filter will not be installed. At least one system call must be defined.
The action to take when any of the system calls listed in
namesis executed. This is required. These are the available action values. The actions that are available depend on the kernel version.
errno- The system call will return
EPERM(permission denied) to the caller.
trace- The kernel will notify a
ptracetracer. If no tracer is present then the system call fails with
ENOSYS(function not implemented).
trap- The kernel will send a
SIGSYSsignal to the calling thread and not execute the system call. The Go runtime will exit.
kill_thread- The kernel will immediately terminate the thread. Other threads will continue to execute.
kill_process- The kernel will terminate the process. Available in Linux 4.14 and later.
log- The kernel will log the system call before executing it. Available in Linux 4.14 and later. (This does not go to the Beat’s log.)
allow- The kernel will allow the system call to execute.
Auditbeat Reports Seccomp Violationsedit
You can use Auditbeat to report any seccomp violations that occur on the system.
The kernel generates an event for each violation and Auditbeat reports the
event.action value will be
violated-seccomp-policy and the event
will contain information about the process and system call.
Intro to Kibana
ELK for Logs & Metrics