On Thu, Nov 14, 2024 at 5:10 PM Song Liu <songliubraving@xxxxxxxx> wrote: > > > > > On Nov 14, 2024, at 4:41 PM, Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > > > On Thu, Nov 14, 2024 at 3:02 PM Song Liu <songliubraving@xxxxxxxx> wrote: > >> > >> > >> > >>> On Nov 14, 2024, at 12:14 PM, Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > >>> > >>> On Thu, Nov 14, 2024 at 12:44 AM Song Liu <song@xxxxxxxxxx> wrote: > >>>> > >>>> + > >>>> + if (bpf_is_subdir(dentry, v->dentry)) > >>>> + ret = FAN_FP_RET_SEND_TO_USERSPACE; > >>>> + else > >>>> + ret = FAN_FP_RET_SKIP_EVENT; > >>> > >>> It seems to me that all these patches and feature additions > >>> to fanotify, new kfuncs, etc are done just to do the above > >>> filtering by subdir ? > >>> > >>> If so, just hard code this logic as an extra flag to fanotify ? > >>> So it can filter all events by subdir. > >>> bpf programmability makes sense when it needs to express > >>> user space policy. Here it's just a filter by subdir. > >>> bpf hammer doesn't look like the right tool for this use case. > >> > >> Current version is indeed tailored towards the subtree > >> monitoring use case. This is mostly because feedback on v1 > >> mostly focused on this use case. V1 itself actually had some > >> other use cases. > > > > like? > > samples/fanotify in v1 shows pattern that matches file prefix > (no BPF). selftests/bpf in v1 shows a pattern where we > propagate a flag in inode local storage from parent directory > to newly created children directory. > > > > >> In practice, fanotify fastpath can benefit from bpf > >> programmability. For example, with bpf programmability, we > >> can combine fanotify and BPF LSM in some security use cases. > >> If some security rules only applies to a few files, a > >> directory, or a subtree, we can use fanotify to only monitor > >> these files. LSM hooks, such as security_file_open(), are > >> always global. The overhead is higher if we are only > >> interested in a few files. > >> > >> Does this make sense? > > > > 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. 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.
