From: Mimi Zohar <zohar@linux.ibm.com>
To: Tushar Sugandhi <tusharsu@linux.microsoft.com>,
stephen.smalley.work@gmail.com, casey@schaufler-ca.com,
agk@redhat.com, snitzer@redhat.com, gmazyland@gmail.com
Cc: tyhicks@linux.microsoft.com, sashal@kernel.org,
jmorris@namei.org, nramas@linux.microsoft.com,
linux-integrity@vger.kernel.org, selinux@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org, dm-devel@redhat.com
Subject: Re: [PATCH v3 1/6] IMA: generalize keyring specific measurement constructs
Date: Mon, 31 Aug 2020 07:55:45 -0400 [thread overview]
Message-ID: <4802c73c2ed22c64ea4f315d3115ead919c3205e.camel@linux.ibm.com> (raw)
In-Reply-To: <20200828015704.6629-2-tusharsu@linux.microsoft.com>
On Thu, 2020-08-27 at 18:56 -0700, Tushar Sugandhi wrote:
> IMA functions such as ima_match_keyring(), process_buffer_measurement(),
> ima_match_policy() etc. handle data specific to keyrings. Currently,
> these constructs are not generic to handle any func specific data.
> This makes it harder to extend without code duplication.
>
> Refactor the keyring specific measurement constructs to be generic and
> reusable in other measurement scenarios.
Mostly this patch changes the variable name from keyring to func_data,
which is good. Other changes should be minimized.
>
> Signed-off-by: Tushar Sugandhi <tusharsu@linux.microsoft.com>
> ---
<snip>
> diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
> index fe1df373c113..8866e84d0062 100644
> --- a/security/integrity/ima/ima_policy.c
> +++ b/security/integrity/ima/ima_policy.c
> @@ -451,15 +451,21 @@ int ima_lsm_policy_change(struct notifier_block *nb, unsigned long event,
> }
>
> /**
> - * ima_match_keyring - determine whether the keyring matches the measure rule
> - * @rule: a pointer to a rule
> - * @keyring: name of the keyring to match against the measure rule
> + * ima_match_rule_data - determine whether the given func_data matches
> + * the measure rule data
> + * @rule: IMA policy rule
> + * @opt_list: rule data to match func_data against
> + * @func_data: data to match against the measure rule data
> + * @allow_empty_opt_list: If true matches all func_data
> * @cred: a pointer to a credentials structure for user validation
> *
> - * Returns true if keyring matches one in the rule, false otherwise.
> + * Returns true if func_data matches one in the rule, false otherwise.
> */
> -static bool ima_match_keyring(struct ima_rule_entry *rule,
> - const char *keyring, const struct cred *cred)
> +static bool ima_match_rule_data(struct ima_rule_entry *rule,
> + const struct ima_rule_opt_list *opt_list,
Ok
> + const char *func_data,
> + bool allow_empty_opt_list,
As the policy is loaded, shouldn't the rules should be checked, not
here on usage?
Mimi
> + const struct cred *cred)
> {
> bool matched = false;
> size_t i;
>
next prev parent reply other threads:[~2020-08-31 11:56 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-28 1:56 [PATCH v3 0/6] IMA: Infrastructure for measurement of critical kernel data Tushar Sugandhi
2020-08-28 1:56 ` [PATCH v3 1/6] IMA: generalize keyring specific measurement constructs Tushar Sugandhi
2020-08-31 11:55 ` Mimi Zohar [this message]
2020-09-11 16:19 ` Tushar Sugandhi
2020-08-28 1:57 ` [PATCH v3 2/6] IMA: change process_buffer_measurement return type from void to int Tushar Sugandhi
2020-08-31 11:36 ` Mimi Zohar
2020-09-11 16:22 ` Tushar Sugandhi
2020-08-28 1:57 ` [PATCH v3 3/6] IMA: update process_buffer_measurement to measure buffer hash Tushar Sugandhi
2020-08-31 17:02 ` Mimi Zohar
2020-09-11 16:44 ` Tushar Sugandhi
2020-08-28 1:57 ` [PATCH v3 4/6] IMA: add policy to measure critical data from kernel components Tushar Sugandhi
2020-08-31 18:15 ` Mimi Zohar
2020-09-11 17:29 ` Tushar Sugandhi
2020-08-28 1:57 ` [PATCH v3 5/6] IMA: add hook " Tushar Sugandhi
2020-08-31 18:23 ` Mimi Zohar
2020-09-11 17:38 ` Tushar Sugandhi
2020-08-28 1:57 ` [PATCH v3 6/6] IMA: validate supported kernel data sources before measurement Tushar Sugandhi
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=4802c73c2ed22c64ea4f315d3115ead919c3205e.camel@linux.ibm.com \
--to=zohar@linux.ibm.com \
--cc=agk@redhat.com \
--cc=casey@schaufler-ca.com \
--cc=dm-devel@redhat.com \
--cc=gmazyland@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=nramas@linux.microsoft.com \
--cc=sashal@kernel.org \
--cc=selinux@vger.kernel.org \
--cc=snitzer@redhat.com \
--cc=stephen.smalley.work@gmail.com \
--cc=tusharsu@linux.microsoft.com \
--cc=tyhicks@linux.microsoft.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 NNTP newsgroup(s).