All of lore.kernel.org
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Stefan Berger <stefanb@linux.ibm.com>
Cc: linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	 linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org,
	 paul@paul-moore.com, jmorris@namei.org, serge@hallyn.com,
	zohar@linux.ibm.com,  roberto.sassu@huawei.com,
	miklos@szeredi.hu,  Christian Brauner <brauner@kernel.org>
Subject: Re: [PATCH 3/5] ima: Reset EVM status upon detecting changes to overlay backing file
Date: Wed, 31 Jan 2024 15:56:28 +0200	[thread overview]
Message-ID: <CAOQ4uxjC=-GOFi3J4ctcNgdMfaerkae30OH9=TkKTWCf=TP95g@mail.gmail.com> (raw)
In-Reply-To: <20240130214620.3155380-4-stefanb@linux.ibm.com>

On Tue, Jan 30, 2024 at 11:46 PM Stefan Berger <stefanb@linux.ibm.com> wrote:
>
> To avoid caching effects to take effect reset the EVM status upon
> detecting changes to the overlay backing files. This prevents a not-yet-
> copied-up file on the overlay from executing if for example the
> security.evm xattr on the file on the 'lower' layer has been removed.
>

And what is expected to happen when file is executed after copy up?
Doesn't this change also protect the same threat after copy up?

> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
> ---
>  include/linux/evm.h               | 8 ++++++++
>  security/integrity/evm/evm_main.c | 7 +++++++
>  security/integrity/ima/ima_main.c | 2 ++
>  3 files changed, 17 insertions(+)
>
> diff --git a/include/linux/evm.h b/include/linux/evm.h
> index d8c0343436b8..e7d6742eee9d 100644
> --- a/include/linux/evm.h
> +++ b/include/linux/evm.h
> @@ -66,6 +66,8 @@ extern int evm_protected_xattr_if_enabled(const char *req_xattr_name);
>  extern int evm_read_protected_xattrs(struct dentry *dentry, u8 *buffer,
>                                      int buffer_size, char type,
>                                      bool canonical_fmt);
> +extern void evm_reset_cache_status(struct dentry *dentry,
> +                                  struct integrity_iint_cache *iint);
>  #ifdef CONFIG_FS_POSIX_ACL
>  extern int posix_xattr_acl(const char *xattrname);
>  #else
> @@ -189,5 +191,11 @@ static inline int evm_read_protected_xattrs(struct dentry *dentry, u8 *buffer,
>         return -EOPNOTSUPP;
>  }
>
> +static inline void evm_reset_cache_status(struct dentry *dentry,
> +                                         struct integrity_iint_cache *iint)
> +{
> +       return;
> +}
> +
>  #endif /* CONFIG_EVM */
>  #endif /* LINUX_EVM_H */
> diff --git a/security/integrity/evm/evm_main.c b/security/integrity/evm/evm_main.c
> index 22a5e26860ea..e96d127b48a2 100644
> --- a/security/integrity/evm/evm_main.c
> +++ b/security/integrity/evm/evm_main.c
> @@ -721,6 +721,13 @@ static void evm_reset_status(struct inode *inode)
>                 iint->evm_status = INTEGRITY_UNKNOWN;
>  }
>
> +void evm_reset_cache_status(struct dentry *dentry,
> +                           struct integrity_iint_cache *iint)
> +{
> +       if (d_real_inode(dentry) != d_backing_inode(dentry))
> +               iint->evm_status = INTEGRITY_UNKNOWN;
> +}
> +
>  /**
>   * evm_revalidate_status - report whether EVM status re-validation is necessary
>   * @xattr_name: pointer to the affected extended attribute name
> diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
> index cc1217ac2c6f..84bdc6e58329 100644
> --- a/security/integrity/ima/ima_main.c
> +++ b/security/integrity/ima/ima_main.c
> @@ -26,6 +26,7 @@
>  #include <linux/ima.h>
>  #include <linux/fs.h>
>  #include <linux/iversion.h>
> +#include <linux/evm.h>
>
>  #include "ima.h"
>
> @@ -295,6 +296,7 @@ static int process_measurement(struct file *file, const struct cred *cred,
>                     !inode_eq_iversion(backing_inode, iint->version)) {
>                         iint->flags &= ~IMA_DONE_MASK;
>                         iint->measured_pcrs = 0;
> +                       evm_reset_cache_status(file_dentry(file), iint);
>                 }
>         }

Make sense.
Unrelated to your change, I now noticed something odd about Mimi's change:

        backing_inode = d_real_inode(file_dentry(file));

I find the choice of variable name to be quite confusing, because ima/evm code
uses  d_backing_inode() all over the place and d_real_inode() !=
d_backing_inode().

First of all, there is never any reason to use d_backing_inode() and its name is
quite confusing in the first place, but it will be a big cleanup to
remove them all.

Suggest to rename the variable to real_inode, same as in
ima_collect_measurement()
to be consistent and reduce confusion factor, which is already high enough ;)

Thanks,
Amir.

  reply	other threads:[~2024-01-31 13:56 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-30 21:46 [PATCH 0/5] evm: Support signatures on stacked filesystem Stefan Berger
2024-01-30 21:46 ` [PATCH 1/5] security: allow finer granularity in permitting copy-up of security xattrs Stefan Berger
2024-01-31 13:25   ` Amir Goldstein
2024-01-31 14:25     ` Christian Brauner
2024-01-31 14:56       ` Stefan Berger
2024-02-01 13:35         ` Christian Brauner
2024-02-01 14:18           ` Amir Goldstein
2024-02-02 11:58             ` Christian Brauner
2024-02-01 15:41     ` Stefan Berger
2024-01-31 16:47   ` kernel test robot
2024-01-31 19:06   ` kernel test robot
2024-01-30 21:46 ` [PATCH 2/5] evm: Implement per signature type decision in security_inode_copy_up_xattr Stefan Berger
2024-01-31 13:28   ` Amir Goldstein
2024-01-30 21:46 ` [PATCH 3/5] ima: Reset EVM status upon detecting changes to overlay backing file Stefan Berger
2024-01-31 13:56   ` Amir Goldstein [this message]
2024-01-31 14:46     ` Stefan Berger
2024-01-30 21:46 ` [PATCH 4/5] evm: Use the real inode's metadata to calculate metadata hash Stefan Berger
2024-01-31  2:10   ` Stefan Berger
2024-01-31 13:16     ` Amir Goldstein
2024-01-31 14:40       ` Stefan Berger
2024-01-31 15:54         ` Amir Goldstein
2024-01-31 17:23           ` Amir Goldstein
2024-01-31 17:46             ` Stefan Berger
2024-02-01 12:10               ` Amir Goldstein
2024-02-01 13:36                 ` Stefan Berger
2024-02-01 14:11                   ` Amir Goldstein
2024-02-01 20:35                     ` Stefan Berger
2024-02-02  9:24                       ` Amir Goldstein
2024-02-02 14:59                         ` Stefan Berger
2024-02-02 15:51                           ` Amir Goldstein
2024-02-02 16:06                             ` Stefan Berger
2024-02-02 16:17                               ` Amir Goldstein
2024-02-02 16:30                                 ` Stefan Berger
2024-01-31 17:25           ` Stefan Berger
2024-01-30 21:46 ` [PATCH 5/5] evm: Enforce signatures on unsupported filesystem for EVM_INIT_X509 Stefan Berger
2024-01-31 14:06   ` Amir Goldstein
2024-02-01 17:53     ` Mimi Zohar
2024-01-31 13:18 ` [PATCH 0/5] evm: Support signatures on stacked filesystem Amir Goldstein
2024-01-31 14:52   ` Stefan Berger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAOQ4uxjC=-GOFi3J4ctcNgdMfaerkae30OH9=TkKTWCf=TP95g@mail.gmail.com' \
    --to=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=jmorris@namei.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=paul@paul-moore.com \
    --cc=roberto.sassu@huawei.com \
    --cc=serge@hallyn.com \
    --cc=stefanb@linux.ibm.com \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.