linux-kernel - Re: [PATCH] fsnotify: add generic perm check for unlink/rmdir

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]

Date:   Wed, 4 May 2022 17:12:16 +0300
From:   Amir Goldstein <amir73il@...il.com>
To:     Jan Kara <jack@...e.cz>
Cc:     Guowei Du <duguoweisz@...il.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        James Morris <jmorris@...ei.org>,
        "Serge E. Hallyn" <serge@...lyn.com>, ast@...nel.org,
        daniel@...earbox.net, andrii@...nel.org, kafai@...com,
        songliubraving@...com, yhs@...com, john.fastabend@...il.com,
        kpsingh@...nel.org,
        LSM List <linux-security-module@...r.kernel.org>,
        Netdev <netdev@...r.kernel.org>, bpf@...r.kernel.org,
        Paul Moore <paul@...l-moore.com>,
        Stephen Smalley <stephen.smalley.work@...il.com>,
        Eric Paris <eparis@...isplace.org>,
        Kees Cook <keescook@...omium.org>, anton@...msg.org,
        ccross@...roid.com, tony.luck@...el.com, selinux@...r.kernel.org,
        duguowei <duguowei@...omi.com>
Subject: Re: [PATCH] fsnotify: add generic perm check for unlink/rmdir

On Tue, May 3, 2022 at 10:49 PM Jan Kara <jack@...e.cz> wrote:
>
> On Wed 04-05-22 02:37:50, Guowei Du wrote:
> > From: duguowei <duguowei@...omi.com>
> >
> > For now, there have been open/access/open_exec perms for file operation,
> > so we add new perms check with unlink/rmdir syscall. if one app deletes
> > any file/dir within pubic area, fsnotify can sends fsnotify_event to
> > listener to deny that, even if the app have right dac/mac permissions.
> >
> > Signed-off-by: duguowei <duguowei@...omi.com>
>
> Before we go into technical details of implementation can you tell me more
> details about the usecase? Why do you need to check specifically for unlink
> / delete?
>
> Also on the design side of things: Do you realize these permission events
> will not be usable together with other permission events like
> FAN_OPEN_PERM? Because these require notification group returning file
> descriptors while your events will return file handles... I guess we should
> somehow fix that.
>

IMO, regardless of file descriptions vs. file handles, blocking events have
no business with async events in the same group at all.
What is the use case for that?
Sure, we have the legacy permission event, but if we do add new blocking
events to UAPI, IMO they should be added to a group that was initialized with a
different class to indicate "blocking events only".

And if we do that, we will not need to pollute the event mask namespace
for every permission event.
When users request to get FAN_UNLINK/FAN_RMDIR events in a
FAN_CLASS_PERMISSION group, internally, that only captures
events reported from fsnotify_perm()/fsnotify_path_perm().

FYI, I do intend to try and upload "pre-modify events" [1].
I had no intention to expose those in fanotify and my implementation
does not have the granularity of UNLINK/RMDIR, but we do need
to think about not duplicating too much code with those overlapping
features.

Thanks,
Amir.

[1] https://github.com/amir73il/linux/commits/fsnotify_pre_modify