[RFC/PATCH v2 bpf-next fanotify 7/7] selftests/bpf: Add test for BPF based fanotify fastpath handler

[Song Liu]

> On Nov 14, 2024, at 5:31 PM, Alexei Starovoitov <alexei.starovoitov at gmail.com> wrote:

[...]

>>> 
>>> Not yet.
>>> This fanotify bpf filtering only reduces the number of events
>>> sent to user space.
>>> How is it supposed to interact with bpf-lsm?
>> 
>> Ah, I didn't explain this part. fanotify+bpf fastpath can
>> do more reducing number of events sent to user space. It can
>> also be used in tracing use cases. For example, we can
>> implement a filetop tool that only monitors a specific
>> directory, a specific device, or a specific mount point.
>> It can also reject some file access (fanotify permission
>> mode). I should have showed these features in a sample
>> and/or selftest.
> 
> I bet bpf tracing can filetop already.
> Not as efficient, but tracing isn't going to be running 24/7.
> 
>> 
>>> Say, security policy applies to /usr/bin/*
>>> so lsm suppose to act on all files and subdirs in there.
>>> How fanotify helps ?
>> 
>> LSM hooks are always global. It is up to the BPF program
>> to filter out irrelevant events. This filtering is
>> sometimes expensive (match d_patch) and inaccurate
>> (maintain a map of target inodes, etc.). OTOH, fanotify
>> has built-in filtering before the BPF program triggers.
>> When multiple BPF programs are monitoring open() for
>> different subdirectories, fanotify based solution will
>> not trigger all these BPF programs for all the open()
>> in the system.
>> 
>> Does this answer the questions?
> 
> No. Above is too much hand waving.
> 
> I think bpf-lsm hook fires before fanotify, so bpf-lsm prog
> implementing some security policy has to decide right
> at the moment what to do with, say, security_file_open().
> fanotify with or without bpf fastpath is too late.

Actually, fanotify in permission mode can stop a file open. 
In current upstream code, fsnotify hook fsnotify_open_perm
is actually part of security_file_open(). It will be moved
to do_dentry_open(), right after security_file_open(). This
move is done by 1cda52f1b461 in linux-next. 

In practice, we are not likely to use BPF LSM and fanotify 
on the same hook at the same time. Instead, we can use 
BPF LSM hooks to gather information and use fanotify to 
make allow/deny decision, or vice versa. 

> In general fanotify is not for security. It's notifying
> user space of events that already happened, so I don't see
> how these two can be combined.

fanotify is actually used by AntiVirus softwares. For 
example, CalmAV (https://www.clamav.net/) uses fanotify 
for its Linux version (it also supports Window and MacOS).


I guess I didn't state the motivation clearly. So let me
try it now. 

Tracing is a critical part of a security solution. With 
LSM, blocking an operation is straightforward. However,
knowing which operation should be blocked is not always 
easy. Also, security hooks (LSM or fanotify) sit in the 
critical path of user requests. It is very important to 
optimize the latency of a security hook. Ideally, the 
tracing logic should gather all the information ahead 
of time, and make the actual hook fast. 

For example, if security_file_open() only needs to read 
a flag from inode local storage, the overhead is minimal 
and predictable. If security_file_open() has to walk the 
dentry tree, or call d_path(), the overhead will be 
much higher. fanotify_file_perm() provides another 
level of optimization over security_file_open(). If a 
file is not being monitored, fanotify will not generate 
the event. 

Security solutions hold higher bars for the tracing logic:

- It needs to be accurate, as false positives and false
  negatives can be very annoying and/or harmful.
- It needs to be efficient, as security daemons run 24/7. 

Given these requirements of security solutions, I believe
it is important to optimize tracing logic as much as 
possible. And BPF based fanotify fastpath handler can
bring non-trivials benefit to BPF based security solutions.

fanotify also has a feature that LSM doesn't provide. 
When a file is accessed, user space daemon can get a 
fd on this file from fanotify. OTOH, LSM can only send
an ino or a path to user space, which is not always 
reliable. 

I hope this starts to make sense...

Thanks,
Song