albinismtip

https://media.ccc.de/v/ASG2018-191-co...

Use cases and implementation challenges

Traceleft is a framework built upon eBPF which allows generation of system events such as file operations and network calls via a configuration driven system. It can act as a foundation for building auditing and incident analysis or monitoring tools that work at the system level and need targeted and filtered information. While traditionally, eBPF based analysis requires writing scripts in a limited C subset, Traceleft aims at providing a configuration based definition system events to be monitored over which filters can be set as required. This talk shares our experiences of developing Traceleft along with some use cases and challenges faced.

The tiny eBPF VM in the Linux kernel has given us unprecedented flexibility in developing tooling for analyzing systems. In this talk we discuss Traceleft - a new auditing and incident analysis framework that can be used to build monitoring tools for filesystem and network events. Traceleft is a configuration driven framework that latches on to syscalls and other relevant Linux kernel functions identified in Traceleft. The eBPF programs are generated, compiled on the fly and inserted in the kernel, based on a set of JSON based configurations. Traceleft supports tracing network calls, file operations such as opening/closing of a target files, for a given set of processes and the aggregation of these events. Traceleft is built using Go and uses Gobpf library and allows the configurations to be sent over the wire using Protobuf format. Traceleft started as a joint effort between ShiftLeft and Kinvolk to develop an easy, repeatable way to provide a configurable way to audit syscalls and classify security events filtered on processes and files. The tools built over Traceleft can be used for live monitoring and alert generation.

Implementing Traceleft presented many challenges.

eBPF tracing programs need to be recompiled for each kernel version and updated for each application profile. It needs to keep track of new processes and match them with new applications in a race-free way. Reading information from different sources bring many race possibilities. Catching syscalls and their parameters bring limitations: matching specific syscalls with specific syscalls or remote hosts for network calls. We will discuss how we overcame some of the challenges.


Suchakra Sharma Alban Crequy

https://cfp.all-systems-go.io/en/ASG2...

https://media.ccc.de/v/ASG2018-230-sy...




Lennart Poettering

https://cfp.all-systems-go.io/en/ASG2...

https://media.ccc.de/v/ASG2018-194-us...



There is so much more than you can so, than just starting and stooping your service, when you start to interact with systemd from within your application. Lets find out!!!

We'll explore how can you interact with systemd from your aplication, by describing how pystemd, a python binding for systemd, was created at facebook, and what type things your programs can take advantage if you just interact with systemd more.

From executing section of your code securely to create development environment on the fly, There is so much more than you can so, than just starting and stooping your service, when you start to interact with systemd from within your application.

Alvaro Leiva Geisse

https://cfp.all-systems-go.io/en/ASG2...

https://media.ccc.de/v/ASG2018-216-sc...



The Linux Audit daemon is responsible for writing audit records to the disk, which you can then access with ausearch and aureport. However, it turned out that parsing and centralizing these records is not as easy as you would hope. Elastic's new Auditbeat fixes this by keeping the original configuration, but ships them to a centralized location where you can easily visualize all events.

You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. This talk shows you what can you do to discover changes, events, and potential security breaches as soon as possible on interactive dashboards. Additionally, we are combining Auditd events with logs, which are security relevant.

Philipp Krenn

https://cfp.all-systems-go.io/en/ASG2...

https://media.ccc.de/v/ASG2018-224-pa...



System containers, the oldest type of containers, focus on running an entire Linux distribution, including all its services in very much the same way it would on a physical system or virtual machine.

System containers come with some unique challenges, users of those containers expect to be able to do pretty much everything that they can on a normal system. This means it’s not possible to restrict those containers quite as much as application containers can be.

It also means that there are extra expectations to be met:


Being able to add/remove devices to/from a running container
Loading security profiles inside a container
Using file capabilities in the container
Mounting file systems
Proper reporting of uptime, resource consumption and limits
Live-migration


In this presentation, we’ll explore some of the existing technologies in use by LXC and LXD to address some of those expectations as well as upcoming kernel and userspace features that will allow system containers to do even more than they do today.

Stéphane Graber

https://cfp.all-systems-go.io/en/ASG2...