Re: fsnotify events for overlayfs real file

On Mon, May 31, 2021 at 09:26:35PM +0300, Amir Goldstein wrote:

On Mon, May 31, 2021 at 6:18 PM Miklos Szeredi [off-list ref] wrote:

quoted

On Tue, 18 May 2021 at 19:56, Amir Goldstein [off-list ref] wrote:

quoted

On Tue, May 18, 2021 at 5:43 PM Miklos Szeredi [off-list ref] wrote:

quoted

On Mon, 10 May 2021 at 18:32, Amir Goldstein [off-list ref] wrote:

quoted

quoted

quoted

My thinking was that we can change d_real() to provide the real path:

static inline struct path d_real_path(struct path *path,
                                    const struct inode *inode)
{
        struct realpath = {};
        if (!unlikely(dentry->d_flags & DCACHE_OP_REAL))
               return *path;
        dentry->d_op->d_real(path->dentry, inode, &realpath);
        return realpath;
}

Real paths are internal, we can't pass them (as fd in permission
events) to userspace.

quoted

quoted

quoted

Another option, instead of getting the realpath, just detect the
mismatch of file_inode(file) != d_inode(path->dentry) in
fanotify_file() and pass FSNOTIFY_EVENT_DENTRY data type
with d_real() dentry to backend instead of FSNOTIFY_EVENT_PATH.

For inotify it should be enough and for fanotify it is enough for
FAN_REPORT_FID and legacy fanotify can report FAN_NOFD,
so at least permission events listeners can identify the situation and
be able to block access to unknown paths.

That sounds like a good short term solution.

It may be a fine academic solution, but I don't think it solves any real
world problem.
I am not aware of any security oriented solutions that use permission
events on inode or directory (let alone sb).

The security oriented users of fanotify are anti-virus on-access
protection engines and those are using mount marks anyway
(dynamically adding them as far as I know).
[cc Marko who may be able to shed some light]

For those products, creating a bind mount inside a new mount ns
may actually escape the on-access policy or the new mount will
also be marked I am not sure. I suppose cloning mount ns may be
prohibited by another LSM or something(?).

Yes, this can be restricted in multiple ways. Three spring to mind right
away:
- procfs: write a really low number to /proc/sys/user/max_mnt_namespaces
- seccomp: prevent the clone3() syscall, prevent the legacy clone()
  syscall with CLONE_NEWNS, prevent unshare(CLONE_NEWNS)
- use LSM

quoted

quoted

Is there a reason for the fake path besides the displayed path in
/proc/self/maps?

I'm not aware of any.

quoted

Does it make sense to keep one realfile with fake path for mmaped
files along side a realfile with private/detached path used for all the
other operations?

This should work, but it would add more open files,

True, but only for the mmaped files.

quoted

so needs some good justifications.

I'm afraid I don't have one yet..
Let's see what the AV vendors have to say.

Thanks,
Amir.