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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <DCE25AB7-E337-4E11-9D57-2880F822BF33@fb.com>
Date: Fri, 15 Nov 2024 01:10:38 +0000
From: Song Liu <songliubraving@...a.com>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
CC: Song Liu <songliubraving@...a.com>, Song Liu <song@...nel.org>,
        bpf
	<bpf@...r.kernel.org>,
        Linux-Fsdevel <linux-fsdevel@...r.kernel.org>,
        LKML
	<linux-kernel@...r.kernel.org>,
        LSM List
	<linux-security-module@...r.kernel.org>,
        Kernel Team <kernel-team@...a.com>,
        Andrii Nakryiko <andrii@...nel.org>, Eddy Z <eddyz87@...il.com>,
        Alexei
 Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Martin
 KaFai Lau <martin.lau@...ux.dev>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
        KP Singh
	<kpsingh@...nel.org>,
        Matt Bobrowski <mattbobrowski@...gle.com>,
        Amir
 Goldstein <amir73il@...il.com>,
        "repnop@...gle.com" <repnop@...gle.com>,
        Jeff
 Layton <jlayton@...nel.org>, Josef Bacik <josef@...icpanda.com>,
        Mickaël Salaün <mic@...ikod.net>,
        "gnoack@...gle.com"
	<gnoack@...gle.com>
Subject: Re: [RFC/PATCH v2 bpf-next fanotify 7/7] selftests/bpf: Add test for
 BPF based fanotify fastpath handler



> On Nov 14, 2024, at 4:41 PM, Alexei Starovoitov <alexei.starovoitov@...il.com> wrote:
> 
> On Thu, Nov 14, 2024 at 3:02 PM Song Liu <songliubraving@...a.com> wrote:
>> 
>> 
>> 
>>> On Nov 14, 2024, at 12:14 PM, Alexei Starovoitov <alexei.starovoitov@...il.com> wrote:
>>> 
>>> On Thu, Nov 14, 2024 at 12:44 AM Song Liu <song@...nel.org> 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.

> 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?

Thanks,
Song