From: Stefan Berger <stefanb@linux.ibm.com>
To: Amir Goldstein <amir73il@gmail.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 09:46:24 -0500 [thread overview]
Message-ID: <c4dc6344-445c-44b8-b5ea-2eb8e2d051d1@linux.ibm.com> (raw)
In-Reply-To: <CAOQ4uxjC=-GOFi3J4ctcNgdMfaerkae30OH9=TkKTWCf=TP95g@mail.gmail.com>
On 1/31/24 08:56, Amir Goldstein wrote:
> 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?
The copy-up may be triggered by changing file content or file metadata.
For EVM file metadata (file attributes and xattrs) are important and if
they change EVM would re-evaluate the file, meaning that it would
determine the file mode bits, uid, gid and xattrs and calculate a hash
over them and compare this hash against the signature in security.evm.
> Doesn't this change also protect the same threat after copy up?
From what I remember from my testing is that file attribute or extended
attribute changes on an already copied-up file were already handled
correctly, meaning they caused the re-evaluation of the file as
described above.
>
>> 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.
next prev parent reply other threads:[~2024-01-31 14:46 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 [this message]
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=c4dc6344-445c-44b8-b5ea-2eb8e2d051d1@linux.ibm.com \
--to=stefanb@linux.ibm.com \
--cc=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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).