Add syscall filtering via seccomp for security #5213

andrewkroh · 2017-09-20T20:47:02Z

The Beat process on Linux can drop privileges to perform specific syscalls (like execve, fork, clone) using a seccomp-bpf filter. This is one-way operation where the process drops privileges and cannot restore them. This limits the damage that can be done if there ever would be a vulnerability.

There is a kernel version requirement, but we can test if the feature is available use it when possible.

I wrote a POC that uses google/kafel, a C library that generates the BPF syscall filter from a policy string. We could statically link with the library (we already use cgo in our Beats since 6.0).

When there is a policy violation the kernel kills the thread rather than the whole process. When it does this an audit event is generated.

FYI you can use /proc/[pid]/status to see if the process has a seccomp filter applied. Look for the Seccomp: line and a value > 0.

We can audit the syscalls used by a Beat by using strace -c [beat cmd] then develop a policy based on that data.

The text was updated successfully, but these errors were encountered:

andrewkroh · 2018-04-08T19:42:07Z

On a related note, when a seccomp policy is violated an event is sent by Auditbeat. I put a sample into this gist.

andrewkroh · 2018-04-12T08:00:22Z

I have opened a PR #6832 to add this feature.

The adds a default seccomp (Secure Computing) filter on Linux that prohibits execve, execveat, fork, and vfork system calls for the Beat process. The seccomp filter policy is configurable as well. You can create your own whitelist or blacklist policy with specific actions. It uses github.com/elastic/go-seccomp-bpf. Whitelist Example ``` seccomp: default_action: errno syscalls: - action: allow names: - open - close - read - exit ``` Blacklist Example ``` seccomp: default_action: allow syscalls: - action: log names: - execve - execveat - fork - vfork - action: kill_process # Requires kernel 4.14+. names: - connect - accept - sendto - recvfrom - sendmsg - recvmsg - bind - listen ``` Closes elastic#5213 Decisions I Made - The default policy is a blacklist because it was the most simple to start with. Whitelisting is recommended because it is more robust. `man seccomp` states "A blacklist will have to be updated whenever a potentially dangerous system call is added (or a dangerous flag or option if those are blacklisted), and it is often possible to alter the representation of a value without altering its meaning, leading to a blacklist bypass." - I chose to not implement argument filtering. It would be useful to have for more granular policies, but I'd rather wait to see how the policies are used and see if argument filtering is required. - The code only makes use of the `seccomp` syscall to install the filter. It does not fallback to the `prctl(2)` `PR_SET_SECCOMP` operation because it does not support flags. The `SECCOMP_FILTER_FLAG_TSYNC` flag is necessary in Go because we have little control over when threads are started, and there are no guarantees that the filter would be installed before other threads start.

The adds a default seccomp (Secure Computing) filter on Linux that prohibits execve, execveat, fork, and vfork system calls for the Beat process. The seccomp filter policy is configurable as well. You can create your own whitelist or blacklist policy with specific actions. It uses github.com/elastic/go-seccomp-bpf. Whitelist Example ``` seccomp: default_action: errno syscalls: - action: allow names: - open - close - read - exit ``` Blacklist Example ``` seccomp: default_action: allow syscalls: - action: log names: - execve - execveat - fork - vfork - action: kill_process # Requires kernel 4.14+. names: - connect - accept - sendto - recvfrom - sendmsg - recvmsg - bind - listen ``` Closes #5213 Decisions I Made - The default policy is a blacklist because it was the most simple to start with. Whitelisting is recommended because it is more robust. `man seccomp` states "A blacklist will have to be updated whenever a potentially dangerous system call is added (or a dangerous flag or option if those are blacklisted), and it is often possible to alter the representation of a value without altering its meaning, leading to a blacklist bypass." - I chose to not implement argument filtering. It would be useful to have for more granular policies, but I'd rather wait to see how the policies are used and see if argument filtering is required. - The code only makes use of the `seccomp` syscall to install the filter. It does not fallback to the `prctl(2)` `PR_SET_SECCOMP` operation because it does not support flags. The `SECCOMP_FILTER_FLAG_TSYNC` flag is necessary in Go because we have little control over when threads are started, and there are no guarantees that the filter would be installed before other threads start.

andrewkroh · 2018-05-12T00:21:06Z

Metricbeat system/diskio uses execve on in Linux. I found seccomp violations in my audit logs and isolated it to the system/diskio test. Here's the cause:

https://github.com/shirou/gopsutil/blob/57f370e13068146efe1cb7129f79e5d51da8a242/disk/disk_linux.go#L373-L389

ruflin · 2018-05-14T11:46:47Z

This is not nice. I wonder if we should make the disk serial number optional and a config option that can be enabled to have by default not execve? Other ideas?

andrewkroh · 2018-05-14T12:59:53Z

There might be another way to get the data with ioctl and HDIO_GET_IDENTITY.

We would need to modify gopsutil to not do the udevadm query.

This PR adds to the seccomp enhancement in elastic#6832 by adding a whitelist policy. The policies are derived from a combination of static analysis of the object code and runtime profiling (to see what the cgo linked libraries are doing). The policies also account for the system calls used while running the system tests with coverage and race detection. Closes elastic#5213

This PR adds to the seccomp enhancement in #6832 by adding a whitelist policy. The policies are derived from a combination of static analysis of the object code and runtime profiling (to see what the cgo linked libraries are doing). The policies also account for the system calls used while running the system tests with coverage and race detection. Closes #5213

andrewkroh · 2018-05-16T14:10:09Z

This feature has been merged into master and will be included in 6.4.

Docs: https://www.elastic.co/guide/en/beats/auditbeat/master/linux-seccomp.html
Developer Readme: https://github.com/elastic/beats/tree/master/libbeat/common/seccomp
Seccomp Policy: https://github.com/elastic/beats/blob/master/libbeat/common/seccomp/policy_linux_amd64.go

The adds a default seccomp (Secure Computing) filter on Linux that prohibits execve, execveat, fork, and vfork system calls for the Beat process. The seccomp filter policy is configurable as well. You can create your own whitelist or blacklist policy with specific actions. It uses github.com/elastic/go-seccomp-bpf. Whitelist Example ``` seccomp: default_action: errno syscalls: - action: allow names: - open - close - read - exit ``` Blacklist Example ``` seccomp: default_action: allow syscalls: - action: log names: - execve - execveat - fork - vfork - action: kill_process # Requires kernel 4.14+. names: - connect - accept - sendto - recvfrom - sendmsg - recvmsg - bind - listen ``` Closes elastic#5213 Decisions I Made - The default policy is a blacklist because it was the most simple to start with. Whitelisting is recommended because it is more robust. `man seccomp` states "A blacklist will have to be updated whenever a potentially dangerous system call is added (or a dangerous flag or option if those are blacklisted), and it is often possible to alter the representation of a value without altering its meaning, leading to a blacklist bypass." - I chose to not implement argument filtering. It would be useful to have for more granular policies, but I'd rather wait to see how the policies are used and see if argument filtering is required. - The code only makes use of the `seccomp` syscall to install the filter. It does not fallback to the `prctl(2)` `PR_SET_SECCOMP` operation because it does not support flags. The `SECCOMP_FILTER_FLAG_TSYNC` flag is necessary in Go because we have little control over when threads are started, and there are no guarantees that the filter would be installed before other threads start.

This PR adds to the seccomp enhancement in elastic#6832 by adding a whitelist policy. The policies are derived from a combination of static analysis of the object code and runtime profiling (to see what the cgo linked libraries are doing). The policies also account for the system calls used while running the system tests with coverage and race detection. Closes elastic#5213

The adds a default seccomp (Secure Computing) filter on Linux that prohibits execve, execveat, fork, and vfork system calls for the Beat process. The seccomp filter policy is configurable as well. You can create your own whitelist or blacklist policy with specific actions. It uses github.com/elastic/go-seccomp-bpf. Whitelist Example ``` seccomp: default_action: errno syscalls: - action: allow names: - open - close - read - exit ``` Blacklist Example ``` seccomp: default_action: allow syscalls: - action: log names: - execve - execveat - fork - vfork - action: kill_process # Requires kernel 4.14+. names: - connect - accept - sendto - recvfrom - sendmsg - recvmsg - bind - listen ``` Closes elastic#5213 Decisions I Made - The default policy is a blacklist because it was the most simple to start with. Whitelisting is recommended because it is more robust. `man seccomp` states "A blacklist will have to be updated whenever a potentially dangerous system call is added (or a dangerous flag or option if those are blacklisted), and it is often possible to alter the representation of a value without altering its meaning, leading to a blacklist bypass." - I chose to not implement argument filtering. It would be useful to have for more granular policies, but I'd rather wait to see how the policies are used and see if argument filtering is required. - The code only makes use of the `seccomp` syscall to install the filter. It does not fallback to the `prctl(2)` `PR_SET_SECCOMP` operation because it does not support flags. The `SECCOMP_FILTER_FLAG_TSYNC` flag is necessary in Go because we have little control over when threads are started, and there are no guarantees that the filter would be installed before other threads start.

This PR adds to the seccomp enhancement in elastic#6832 by adding a whitelist policy. The policies are derived from a combination of static analysis of the object code and runtime profiling (to see what the cgo linked libraries are doing). The policies also account for the system calls used while running the system tests with coverage and race detection. Closes elastic#5213

jsoriano · 2018-06-01T12:12:18Z

I have opened a PR to get disk serial from udev data or sysfs without using udevadm or any other command shirou/gopsutil#532

ruflin · 2018-06-01T12:29:46Z

Great. If it doesn't get merge soonish we can also switch to our own fork for now until it is merged.

jsoriano · 2018-07-01T19:57:54Z

gopsutil 2.18.06 released, PR created to update it #7483

andrewkroh added the enhancement label Sep 20, 2017

andrewkroh mentioned this issue Feb 9, 2018

[WIP] Collect domain memory stat from KVM #6265

Merged

andrewkroh mentioned this issue Apr 12, 2018

Add a configurable seccomp filter on Linux #6832

Merged

3 tasks

adriansr closed this as completed in #6832 May 7, 2018

andrewkroh mentioned this issue May 11, 2018

Add seccomp whitelist policies for each Beat #7081

Merged

andrewkroh reopened this May 14, 2018

adriansr closed this as completed in #7081 May 16, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add syscall filtering via seccomp for security #5213

Add syscall filtering via seccomp for security #5213

andrewkroh commented Sep 20, 2017 •

edited

Loading

andrewkroh commented Apr 8, 2018

andrewkroh commented Apr 12, 2018

andrewkroh commented May 12, 2018

ruflin commented May 14, 2018

andrewkroh commented May 14, 2018

andrewkroh commented May 16, 2018

jsoriano commented Jun 1, 2018

ruflin commented Jun 1, 2018

jsoriano commented Jul 1, 2018

Add syscall filtering via seccomp for security #5213

Add syscall filtering via seccomp for security #5213

Comments

andrewkroh commented Sep 20, 2017 • edited Loading

andrewkroh commented Apr 8, 2018

andrewkroh commented Apr 12, 2018

andrewkroh commented May 12, 2018

ruflin commented May 14, 2018

andrewkroh commented May 14, 2018

andrewkroh commented May 16, 2018

jsoriano commented Jun 1, 2018

ruflin commented Jun 1, 2018

jsoriano commented Jul 1, 2018

andrewkroh commented Sep 20, 2017 •

edited

Loading