* Add BPF 101 README file
Added a README document to introduce and guide new users on BPF (Berkeley Packet Filter) code writing. The file includes useful links, described the environment setup and outlined the supported architectures. This will provide the necessary resources and steps on how to use and develop BPF codes.
* Improve README with BPF code structure and usage details
Extended the README document in the BPF directory to include a comprehensive explanation on the structure of BPF code and its usage aspects. This elaboration covers the distinction between BPF program and user space code, their locations in the repository, certain limitations, their compilation process, as well as compatibility issues concerning the `libbpfgo` library. This addition is expected to provide clearer guidance for developers working with BPF code in this project.
* Add BPF helpers documentation link and license details to README
Added a link to the BPF helpers documentation in the README for easy reference. Also included detailed information about the license requirement for BPF programs in the kernel. This is aimed to inform developers about the GPL default setting for the license field in ELF files, and the limitations imposed by using the `Dual BSD/GPL` license in Teleport. Instructions for enabling all BPF features have also been provided.
* Add logging section to BPF README.md
Included a new section in the BPF README.md file detailing how to enable logging within BPF programs. This change provides clear instructions and a useful resource link to developers on how to set the license to 'GPL' for BPF programs, and how to use the 'bpf_printk' helper for logging messages to the kernel log. Adding this documentation promotes a better understanding of BPF logging functions and their license requirements.
* Enhance BPF README with BPF-user space communication info
Expanded the BPF README.md file to include a section about communication between BPF programs and user space via maps. This addition provides a valuable explanation and example of how both user space and BPF programs can access maps. This highlights the interaction between BPF and user space, educating developers on properly utilizing BPF-helper for map access in BPF programs and 'libbpfgo' library in user space.
* Apply suggestions from code review
Co-authored-by: Alan Parra <alan.parra@goteleport.com>
* Update BPF README with additional details and instructions.
This commit expands on the instructions for setting up BPF, specifically clarifying that 'clang' can be installed through the 'apt install clang' command. A section detailing the requirements for libbpf installation has also been added for further clarity. Moreover, the BPF utilization in Teleport has been further explained, highlighting its usage for enhanced session recording and restricted networking. Lastly, the instructions for enabling LSM hooks on Ubuntu systems have been provided. This commit aims to provide comprehensive and updated information for configuring and understanding BPF usage.
* Apply suggestions from code review
Co-authored-by: Alan Parra <alan.parra@goteleport.com>
* Update bpf/README.md
Co-authored-by: Anton Miniailo <anton@goteleport.com>
---------
Co-authored-by: Alan Parra <alan.parra@goteleport.com>
Co-authored-by: Anton Miniailo <anton@goteleport.com>
* Move BPF event filtering to the kernel
#19354 moved filtering of disk events to the kernel space. This PR continues work in this area and moves all events to be filtered in the kernel space.
* Improve comments.
Minor code fixes.
Test ARM64 assets build
Use all available cores when building Clang
Add test trigger
Update assets buildbox name
Build all dependencies on ARM64 including BPF
This PR moves the filtering from the userspace to the kernel, where we can filter them earlier and not pay for sending all events to our userspace process. Because the filtering happens in the kernel, the BPF test had to be rewritten to execute events in a sub-cgroup instead of the global one.
Adds the ability to block network traffic on SSH sessions.
The deny/allow lists of IPs are specified in teleport.yaml file.
Supports both IPv4 and IPv6 communication.
This feature currently relies on enhanced recording for
cgroup management so that needs to be enabled as well.
-- Design rationale:
This patch uses Linux Security Module (LSM) hooks, specifically
security_socket_connect and security_socket_sendmsg, to control
egress traffic. The LSM provides two advantages over socket filtering
program types.
- It's executed early enough that the task information is available.
This makes it easy to report PID, COMM, etc.
- It becomes a model for extending restrictions beyond networking.
The set of enforced cgroups is stored in a BPF hash map and the
deny/allow lists are stored in BPF trie maps. An IP address is
first checked against the allow list. If found, it's checked for
an override in the deny list. The policy is default deny. However,
the absence of the NetworkRestrictions API object is allow all.
IPv4 addresses are additionally registered in IPv6 trie (as mapped)
to account for dual stacks. However it is unclear if this is sufficient
as 4-to-6 transition methods utilize a multitude of translation and
tunneling methods.
