From: Roberto Sassu <roberto.sassu@polito.it>
To: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org, jmorris@namei.org,
Rajiv Andrade <srajiv@linux.vnet.ibm.com>
Subject: Re: [PATCH 1/2] ima: split ima_add_digest_entry() function
Date: Wed, 16 Nov 2011 15:37:14 +0100 [thread overview]
Message-ID: <4EC3CA9A.3070401@polito.it> (raw)
In-Reply-To: <1321450690.1901.24.camel@falcor>
On 11/16/2011 02:38 PM, Mimi Zohar wrote:
> On Wed, 2011-11-16 at 11:10 +0100, Roberto Sassu wrote:
>> The ima_add_digest_entry() function has been split in order to avoid
>> adding an entry in the measurements list for which the PCR extend
>> operation subsequently fails. Required memory is allocated earlier in the
>> new function ima_prepare_template_entry() and the template entry is added
>> after ima_pcr_extend().
>>
>> Signed-off-by: Roberto Sassu<roberto.sassu@polito.it>
>
Hi Mimi
i don't know if this condition can happen, but suppose that
for whatever reason the PCR extend fails. In this case, since
the PCR is not extended, the measurements list can be modified,
by removing the non-measured entry, without this fact being
detected by the verifier. So, probably we can avoid to display
the entry.
> Not adding a measurement would certainly resolve the problems with
> validating the measurement list against the PCR, but poses a risk that
> something was read/executed that wasn't included in the measurement
> list. One solution would be for IMA to queue these measurements for the
> TPM, but, I think, a better solution would be for the tpm driver to
> queue them.
>
I think this solution will not prevent that some measurements
are not included in the list, because, if i understand correctly,
queuing an operation means that the latter can be executed after
the list mutex is released. After that, a malicious program may
corrupt the queue, hiding its presence to the verifier.
There is also another issue to solve (but i don't know if this
can really happen): a process requests a system call but, at the
time IMA is invoked, there is not enough memory for allocating
a template entry. However, it may continue its execution if,
meanwhile, some memory resources are freed.
In my opinion, a viable solution may be to return an error in
the IMA hooks when an inode cannot be properly measured (exactly
as the ima-appraisal extension does). For compatibility reasons,
this feature can be disabled by introducing a new kernel parameter
that tell IMA to ignore errors.
Thanks
Roberto Sassu
> thanks,
>
> Mimi
>
>> ---
>> security/integrity/ima/ima_queue.c | 35 ++++++++++++++++++++++++++---------
>> 1 files changed, 26 insertions(+), 9 deletions(-)
>>
>> diff --git a/security/integrity/ima/ima_queue.c b/security/integrity/ima/ima_queue.c
>> index 8e28f04..ddc7e18 100644
>> --- a/security/integrity/ima/ima_queue.c
>> +++ b/security/integrity/ima/ima_queue.c
>> @@ -59,30 +59,41 @@ static struct ima_queue_entry *ima_lookup_digest_entry(u8 *digest_value)
>> return ret;
>> }
>>
>> -/* ima_add_template_entry helper function:
>> - * - Add template entry to measurement list and hash table.
>> +/* ima_prepare_template_entry helper function:
>> + * - prepare template entry before adding it to the measurement list.
>> *
>> * (Called with ima_extend_list_mutex held.)
>> */
>> -static int ima_add_digest_entry(struct ima_template_entry *entry)
>> +static struct ima_queue_entry *ima_prepare_template_entry(
>> + struct ima_template_entry *entry)
>> {
>> struct ima_queue_entry *qe;
>> - unsigned int key;
>>
>> qe = kmalloc(sizeof(*qe), GFP_KERNEL);
>> if (qe == NULL) {
>> pr_err("IMA: OUT OF MEMORY ERROR creating queue entry.\n");
>> - return -ENOMEM;
>> + goto out;
>> }
>> qe->entry = entry;
>> +out:
>> + return qe;
>> +}
>> +
>> +/* ima_add_digest_entry helper function:
>> + * - Add template entry to measurement list and hash table.
>> + *
>> + * (Called with ima_extend_list_mutex held.)
>> + */
>> +static void ima_add_digest_entry(struct ima_queue_entry *qe)
>> +{
>> + unsigned int key;
>>
>> INIT_LIST_HEAD(&qe->later);
>> list_add_tail_rcu(&qe->later,&ima_measurements);
>>
>> atomic_long_inc(&ima_htable.len);
>> - key = ima_hash_key(entry->digest);
>> + key = ima_hash_key(qe->entry->digest);
>> hlist_add_head_rcu(&qe->hnext,&ima_htable.queue[key]);
>> - return 0;
>> }
>>
>> static int ima_pcr_extend(const u8 *hash)
>> @@ -104,6 +115,7 @@ static int ima_pcr_extend(const u8 *hash)
>> int ima_add_template_entry(struct ima_template_entry *entry, int violation,
>> const char *op, struct inode *inode)
>> {
>> + struct ima_queue_entry *qe;
>> u8 digest[IMA_DIGEST_SIZE];
>> const char *audit_cause = "hash_added";
>> int audit_info = 1;
>> @@ -118,10 +130,11 @@ int ima_add_template_entry(struct ima_template_entry *entry, int violation,
>> }
>> }
>>
>> - result = ima_add_digest_entry(entry);
>> - if (result< 0) {
>> + qe = ima_prepare_template_entry(entry);
>> + if (qe == NULL) {
>> audit_cause = "ENOMEM";
>> audit_info = 0;
>> + result = -ENOMEM;
>> goto out;
>> }
>>
>> @@ -132,7 +145,11 @@ int ima_add_template_entry(struct ima_template_entry *entry, int violation,
>> if (result != 0) {
>> audit_cause = "TPM error";
>> audit_info = 0;
>> + kfree(qe);
>> + goto out;
>> }
>> +
>> + ima_add_digest_entry(qe);
>> out:
>> mutex_unlock(&ima_extend_list_mutex);
>> integrity_audit_msg(AUDIT_INTEGRITY_PCR, inode,
>
>
next prev parent reply other threads:[~2011-11-16 14:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-16 10:10 [PATCH 1/2] ima: split ima_add_digest_entry() function Roberto Sassu
2011-11-16 10:10 ` [PATCH 2/2] ima: free memory of unused template entries Roberto Sassu
2011-11-16 13:38 ` [PATCH 1/2] ima: split ima_add_digest_entry() function Mimi Zohar
2011-11-16 14:37 ` Roberto Sassu [this message]
2011-11-16 18:52 ` Rajiv Andrade
2011-11-17 10:57 ` Roberto Sassu
2011-11-17 21:15 ` Mimi Zohar
2011-11-18 10:27 ` Roberto Sassu
2011-11-18 17:31 ` Mimi Zohar
2011-11-21 14:52 ` Roberto Sassu
2011-12-04 23:36 ` Mimi Zohar
2011-12-05 10:04 ` Roberto Sassu
2011-12-05 13:03 ` Mimi Zohar
2011-12-05 13:56 ` Roberto Sassu
2011-12-05 20:57 ` Mimi Zohar
2011-12-06 10:27 ` Roberto Sassu
2011-12-06 14:24 ` Mimi Zohar
2011-12-06 14:50 ` Roberto Sassu
2011-12-07 13:33 ` Kasatkin, Dmitry
2011-12-07 14:28 ` Roberto Sassu
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=4EC3CA9A.3070401@polito.it \
--to=roberto.sassu@polito.it \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=srajiv@linux.vnet.ibm.com \
--cc=zohar@linux.vnet.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.