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
Subject: Re: [PATCH 4/5] evm: Use the real inode's metadata to calculate metadata hash
Date: Wed, 31 Jan 2024 19:23:03 +0200	[thread overview]
Message-ID: <CAOQ4uxigdNeE+2nfr4VxS9piQf5hez=ryT0a-jzW+tW0BT-zuw@mail.gmail.com> (raw)
In-Reply-To: <CAOQ4uxi6Te8izWpXROthknRaXrVA9jho5nbc+mkuQDrcTLY44Q@mail.gmail.com>

On Wed, Jan 31, 2024 at 5:54 PM Amir Goldstein <amir73il@gmail.com> wrote:
>
> On Wed, Jan 31, 2024 at 4:40 PM Stefan Berger <stefanb@linux.ibm.com> wrote:
> >
> >
> >
> > On 1/31/24 08:16, Amir Goldstein wrote:
> > > On Wed, Jan 31, 2024 at 4:11 AM Stefan Berger <stefanb@linux.ibm.com> wrote:
> > >>
> > >>
> > >>
> > >> On 1/30/24 16:46, Stefan Berger wrote:
> > >>> Changes to the file attribute (mode bits, uid, gid) on the lower layer
> > >>> are not take into account when d_backing_inode() is used when a file is
> > >>> accessed on the overlay layer and this file has not yet been copied up.
> > >>> This is because d_backing_inode() does not return the real inode of the
> > >>> lower layer but instead returns the backing inode which holds old file
> > >>> attributes. When the old file attributes are used for calculating the
> > >>> metadata hash then the expected hash is calculated and the file then
> > >>> mistakenly passes signature verification. Therefore, use d_real_inode()
> > >>> which returns the inode of the lower layer for as long as the file has
> > >>> not been copied up and returns the upper layer's inode otherwise.
> > >>>
> > >>> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
> > >>> ---
> > >>>    security/integrity/evm/evm_crypto.c | 2 +-
> > >>>    1 file changed, 1 insertion(+), 1 deletion(-)
> > >>>
> > >>> diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c
> > >>> index b1ffd4cc0b44..2e48fe54e899 100644
> > >>> --- a/security/integrity/evm/evm_crypto.c
> > >>> +++ b/security/integrity/evm/evm_crypto.c
> > >>> @@ -223,7 +223,7 @@ static int evm_calc_hmac_or_hash(struct dentry *dentry,
> > >>>                                 size_t req_xattr_value_len,
> > >>>                                 uint8_t type, struct evm_digest *data)
> > >>>    {
> > >>> -     struct inode *inode = d_backing_inode(dentry);
> > >>> +     struct inode *inode = d_real_inode(dentry);
> > >>>        struct xattr_list *xattr;
> > >>>        struct shash_desc *desc;
> > >>>        size_t xattr_size = 0;
> > >>
> > >> We need this patch when NOT activating CONFIG_OVERLAY_FS_METACOPY but
> > >> when setting CONFIG_OVERLAY_FS_METACOPY=y it has to be reverted...  I am
> > >> not sure what the solution is.
> > >
> > > I think d_real_inode() does not work correctly for all its current users for
> > > a metacopy file.
> > >
> > > I think the solution is to change d_real_inode() to return the data inode
> > > and add another helper to get the metadata inode if needed.
> > > I will post some patches for it.
> >
> > I thought that we may have to go through vfs_getattr() but even better
> > if we don't because we don't have the file *file anywhere 'near'.
> >
> > >
> > > However, I must say that I do not know if evm_calc_hmac_or_hash()
> > > needs the lower data inode, the upper metadata inode or both.
> >
> > What it needs are data structures with mode bits, uid, and gid that stat
> > in userspace would show.
> >
> >
>
> With or without metacopy enabled, an overlay inode st_uid st_gid st_mode
> are always taken from the upper most inode which is what d_real_inode()
> currently returns, so I do not understand what the problem is.
>

No, I was wrong. It is the other way around.
d_real_inode() always returns the real data inode and you need the
upper most real inode.

You can try this:

 -     struct inode *inode = d_backing_inode(dentry);
+     struct inode *inode = d_inode(d_real(dentry, false));

With the changes in:

https://github.com/amir73il/linux/commits/overlayfs-devel/

Not thoroughly tested...

Thanks,
Amir.

  reply	other threads:[~2024-01-31 17:23 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
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 [this message]
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='CAOQ4uxigdNeE+2nfr4VxS9piQf5hez=ryT0a-jzW+tW0BT-zuw@mail.gmail.com' \
    --to=amir73il@gmail.com \
    --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.