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: <CAOQ4uxjDQO91cjA0sgyPStkwc_7+NxAOhyve94qUvXSM3ytk1g@mail.gmail.com>
Date: Fri, 12 Apr 2024 21:08:17 +0300
From: Amir Goldstein <amir73il@...il.com>
To: Stefan Berger <stefanb@...ux.ibm.com>
Cc: linux-integrity@...r.kernel.org, linux-unionfs@...r.kernel.org, 
	linux-kernel@...r.kernel.org, zohar@...ux.ibm.com, roberto.sassu@...wei.com, 
	miklos@...redi.hu, Christian Brauner <brauner@...nel.org>
Subject: Re: [RFC 2/2] ima: Fix detection of read/write violations on stacked filesystems

On Fri, Apr 12, 2024 at 5:01 PM Stefan Berger <stefanb@...ux.ibm.com> wrote:
>
> On a stacked filesystem, when one process opens the file holding a file's
> data (e.g., on upper or lower layer on overlayfs) then issue a violation
> when another process opens the file for reading on the top layer (overlay
> layer on overlayfs). This then provides similar behavior to the existing
> case where a violation is generated when one process opens a file for
> writing and another one opens the same file for reading. On stacked
> filesystem also search all the lower layers for relevant files opened for
> writing and issue the violation if one is found.
>
> Signed-off-by: Stefan Berger <stefanb@...ux.ibm.com>
> ---
>  security/integrity/ima/ima_main.c | 27 ++++++++++++++++++++++-----
>  1 file changed, 22 insertions(+), 5 deletions(-)
>
> diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
> index f04f43af651c..590dd9d5d99a 100644
> --- a/security/integrity/ima/ima_main.c
> +++ b/security/integrity/ima/ima_main.c
> @@ -121,8 +121,11 @@ static void ima_rdwr_violation_check(struct file *file,
>                                      const char **pathname,
>                                      char *filename)
>  {
> +       struct inode *real_inode = d_real_inode(file_dentry(file));
>         struct inode *inode = file_inode(file);
> +       struct dentry *fd_dentry, *d;
>         fmode_t mode = file->f_mode;
> +       struct inode *fd_inode;
>         bool send_tomtou = false, send_writers = false;
>
>         if (mode & FMODE_WRITE) {
> @@ -134,11 +137,25 @@ static void ima_rdwr_violation_check(struct file *file,
>                                                 &iint->atomic_flags))
>                                 send_tomtou = true;
>                 }
> -       } else {
> -               if (must_measure)
> -                       set_bit(IMA_MUST_MEASURE, &iint->atomic_flags);
> -               if (inode_is_open_for_write(inode) && must_measure)
> -                       send_writers = true;
> +       } else if (must_measure) {
> +               set_bit(IMA_MUST_MEASURE, &iint->atomic_flags);
> +
> +               if (inode == real_inode) {
> +                       if (inode_is_open_for_write(inode))
> +                               send_writers = true;
> +               } else {
> +                       d = d_real(file_dentry(file), D_REAL_FILEDATA);
> +                       do {
> +                               fd_dentry = d;
> +                               fd_inode = d_inode(fd_dentry);
> +                               if (inode_is_open_for_write(fd_inode)) {
> +                                       send_writers = true;
> +                                       break;
> +                               }
> +                               /* next layer of stacked fs */
> +                               d = d_real(fd_dentry, D_REAL_FILEDATA);
> +                       } while (d != fd_dentry);
> +               }

The idea of digging though ovl layers feels wrong to me.
As Miklos is the designer of overlayfs and its vfs architecture,
I am deferring the call about adding this interface to Miklos.

Thanks,
Amir.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ