[PATCH RFC v1 4/7] integrity: Fix inode numbers in audit records

Roberto Sassu roberto.sassu at huaweicloud.com
Fri Oct 11 12:45:12 UTC 2024


On Fri, 2024-10-11 at 14:38 +0200, Mickaël Salaün wrote:
> On Fri, Oct 11, 2024 at 01:34:39PM +0200, Roberto Sassu wrote:
> > On Fri, 2024-10-11 at 12:15 +0200, Mickaël Salaün wrote:
> > > On Thu, Oct 10, 2024 at 09:20:52PM -0400, Paul Moore wrote:
> > > > On Oct 10, 2024 =?UTF-8?q?Micka=C3=ABl=20Sala=C3=BCn?= <mic at digikod.net> wrote:
> > > > > 
> > > > > Use the new inode_get_ino() helper to log the user space's view of
> > > > > inode's numbers instead of the private kernel values.
> > > > > 
> > > > > Cc: Mimi Zohar <zohar at linux.ibm.com>
> > > > > Cc: Roberto Sassu <roberto.sassu at huawei.com>
> > > > > Cc: Dmitry Kasatkin <dmitry.kasatkin at gmail.com>
> > > > > Cc: Eric Snowberg <eric.snowberg at oracle.com>
> > > > > Signed-off-by: Mickaël Salaün <mic at digikod.net>
> > > > > ---
> > > > >  security/integrity/integrity_audit.c | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > Should we also need to update the inode value used in hmac_add_misc()?
> > > 
> > > I'm not sure what the impact will be wrt backward compatibility. Mimi,
> > > Roberto?
> > 
> > Changing the inode number the HMAC was calculated with has the
> > potential effect of making the file inaccessible.
> > 
> > In order to use the new inode number, we need to define a new EVM xattr
> > type, and update the previous xattr version with the new one. We could
> > deprecate the old xattr version after a while (to be discussed with
> > Mimi).
> 
> That was my though.  I don't we should patch hmac_add_misc() because it
> is already in the IMA/EVM ABI and not directly reflected to user space.
> The issue might be that user space cannot recreate this hmac because
> this private inode number is not known to user space, but I don't know
> if there is such user space implementation of IMA/EVM.

EVM will recalculate the HMAC of the file metadata based on the new
inode number, and will conclude that metadata was corrupted (same as if
someone modified a protected xattr during an offline attack).

Roberto

> > 
> > Roberto
> > 
> > > > 
> > > > diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c
> > > > index 7c06ffd633d2..68ae454e187f 100644
> > > > --- a/security/integrity/evm/evm_crypto.c
> > > > +++ b/security/integrity/evm/evm_crypto.c
> > > > @@ -155,7 +155,7 @@ static void hmac_add_misc(struct shash_desc *desc, struct inode *inode,
> > > >          * signatures
> > > >          */
> > > >         if (type != EVM_XATTR_PORTABLE_DIGSIG) {
> > > > -               hmac_misc.ino = inode->i_ino;
> > > > +               hmac_misc.ino = inode_get_ino(inode->i_ino);
> > > >                 hmac_misc.generation = inode->i_generation;
> > > >         }
> > > >         /* The hmac uid and gid must be encoded in the initial user
> > > > 
> > > > --
> > > > paul-moore.com
> > 
> > 




More information about the Linux-security-module-archive mailing list