linux-kernel - Re: [RFC bpf-next fanotify 1/5] fanotify: Introduce 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: <AE6EEE9B-B84F-4097-859B-B4509F2B6AF8@fb.com>
Date: Thu, 7 Nov 2024 19:13:23 +0000
From: Song Liu <songliubraving@...a.com>
To: Jan Kara <jack@...e.cz>
CC: Song Liu <song@...nel.org>, bpf <bpf@...r.kernel.org>,
        Linux-Fsdevel
	<linux-fsdevel@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Kernel
 Team <kernel-team@...a.com>,
        Andrii Nakryiko <andrii@...nel.org>,
        Eduard
 Zingerman <eddyz87@...il.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel
 Borkmann <daniel@...earbox.net>,
        Martin KaFai Lau <martin.lau@...ux.dev>,
        Al
 Viro <viro@...iv.linux.org.uk>,
        Christian Brauner <brauner@...nel.org>, KP
 Singh <kpsingh@...nel.org>,
        Matt Bobrowski <mattbobrowski@...gle.com>,
        Amir
 Goldstein <amir73il@...il.com>,
        "repnop@...gle.com" <repnop@...gle.com>,
        "jlayton@...nel.org" <jlayton@...nel.org>,
        Josef Bacik <josef@...icpanda.com>
Subject: Re: [RFC bpf-next fanotify 1/5] fanotify: Introduce fanotify fastpath
 handler



> On Nov 7, 2024, at 2:48 AM, Jan Kara <jack@...e.cz> wrote:
> 
> On Tue 29-10-24 16:12:40, Song Liu wrote:
>> fanotify fastpath handler enables handling fanotify events within the
>> kernel, and thus saves a trip to the user space. fanotify fastpath handler
>> can be useful in many use cases. For example, if a user is only interested
>> in events for some files in side a directory, a fastpath handler can be
>> used to filter out irrelevant events.
>> 
>> fanotify fastpath handler is attached to fsnotify_group. At most one
>> fastpath handler can be attached to a fsnotify_group. The attach/detach
>> of fastpath handlers are controlled by two new ioctls on the fanotify fds:
>> FAN_IOC_ADD_FP and FAN_IOC_DEL_FP.
>> 
>> fanotify fastpath handler is packaged in a kernel module. In the future,
>> it is also possible to package fastpath handler in a BPF program. Since
>> loading modules requires CAP_SYS_ADMIN, _loading_ fanotify fastpath
>> handler in kernel modules is limited to CAP_SYS_ADMIN. However,
>> non-SYS_CAP_ADMIN users can _attach_ fastpath handler loaded by sys admin
>> to their fanotify fds. To make fanotify fastpath handler more useful
>> for non-CAP_SYS_ADMIN users, a fastpath handler can take arguments at
>> attach time.
> 
> Hum, I'm not sure I'd be fine as an sysadmin to allow arbitary users to
> attach arbitrary filters to their groups. I might want some filters for
> priviledged programs which know what they are doing (e.g. because the
> filters are expensive) and other filters may be fine for anybody. But
> overall I'd think we'll soon hit requirements for permission control over
> who can attach what... Somebody must have created a solution for this
> already?

I have "flags" in fanotify_fastpath_ops. In an earlier version of my 
local code, I actually have "SYS_ADMIN_ONLY" flag that specifies some
filters are only available to users with CAP_SYS_ADMIN. I removed this 
flag later before sending the first RFC for simplicity. 

The model here (fast path loaded in kernel modules) is similar to 
different TCP congestion control algorithms. Regular user can choose 
which algorithm to use for each TCP connection. This model is 
straightforward because the kernel modules are global. With BPF, we 
have the option not to add the fast path to a global list, so that 
whoever loads the fast path can attach it to specific group (I didn't
include this model in the RFC).

For the first version, I think a SYS_ADMIN_ONLY flag would be good
enough?

Thanks,
Song