Channels
android_tests
apple-silicon
arm-architecture
auditing-warroom
aws
carving
code-review
community-feeds
core
darkbytes
doorman
ebpf
eclecticiq-polylogyx-extension
extensions
file-carving
fim
fleet
fleet-dev
fleetosquery
foundation
fuzzing
general
golang
goquery
infrastructure
jobs
kolide
linen-dev
linux
macos
officehours
osctrl
plugins
process-auditing
querycon
queryhub
random
selfgroup
sql
tls
uptycs
vendor-feeds
website
windows
zeek
zentral
zercurity
Title
s
Sunil Kahalekar
02/27/2023, 6:55 AMHey hi all, I try to implement bpf file events table. Please go through raised PR. Implementations for bpf based file events i.e inclusion of bpf_file_events table for Linux #7947. https://github.com/osquery/osquery/pull/7947
a
alessandrogario
02/27/2023, 11:59 AMHello Sunil, we have approved the CI runner and updated title/labels
Is this part of a larger effort, and is it going to be followed up by additional pull requests?
s
Sunil Kahalekar
02/27/2023, 2:25 PMthanks for your replied. I will take necessary action as required and update my PR soon.
Same PR modification is Ok or need new additional PR.
a
alessandrogario
02/27/2023, 2:27 PMAdditional changes related to that table are good in the same PR.
But if there are more complex features planned for this table or future tables, it would need to be discussed in a blueprint issue first
s
Sunil Kahalekar
02/27/2023, 2:32 PMGreat I will get back to you soon. Thanks.
a
alessandrogario
02/27/2023, 2:33 PMElaborating more on this: it's unlikely that this can become a file integrity monitoring table comparable to file_events
The inotify approach performs a lot better than BPF in this specific case, since it does not need to trace many system calls
Through the inotify watchers, it is possible to know when a file or folder is changed in a compact way
With the current implementation of BPF (through the ebpfpub library, using system calls) it is not possible to trace write events without causing performance issues
s
Sunil Kahalekar
02/27/2023, 2:36 PMIt is useful for monitoring container-related file activity
a
alessandrogario
02/27/2023, 2:36 PMThe problem in practice is that everything on Linux can go through the generic write() system calls: files, network sockets, even the terminal output
So it would not be possible to trace much more than just the simple open() (and variants). This means that file_events is still a better choice
s
Sunil Kahalekar
02/27/2023, 2:39 PMfile_events covers docker and container file activity?
a
alessandrogario
02/27/2023, 2:40 PMIt does not, but BPF right now only has limited support for it through the ebpfpub library
The cgroup id (cid field) is not very useful to determine which container is doing what. it's also not possible to understand whether it's a nested container or not
The PR is also not compatible with containers, since the configuration function will enumerate files on disk using the host mount namespace
Containers however are using their own mount namespace, which is not readily accessible to the host (depending on whether the container was started before or after osquery, and on what kind of technology the container runtime is using)
We do have a better way to approach this (see https://github.com/osquery/osquery/pull/7773), but it's still being worked on (also, it only supports kernels >= 5.4)
There's a chance the kernel requirement could be lowered using external BTF files but that is something we have yet to explore