> On Nov 14, 2024, at 5:31 PM, Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> 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
