All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roberto Sassu <roberto.sassu@huawei.com>
To: Ken Goldman <kgold@linux.vnet.ibm.com>,
	<linux-ima-devel@lists.sourceforge.net>
Cc: <linux-security-module@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [Linux-ima-devel] [PATCH 0/7] IMA: new parser for ima_restore_measurement_list()
Date: Wed, 24 May 2017 10:18:46 +0200	[thread overview]
Message-ID: <e7386c0d-332b-1d61-a927-ad9b9dcd1449@huawei.com> (raw)
In-Reply-To: <08bd9fcb-d3ba-e76e-928e-f569e8a4be74@linux.vnet.ibm.com>

On 5/23/2017 10:48 PM, Ken Goldman wrote:
> On 5/18/2017 5:38 AM, Roberto Sassu wrote:
>> On 5/17/2017 6:28 PM, Ken Goldman wrote:
>>> On 5/17/2017 3:25 AM, Roberto Sassu wrote:
>>>>
>>>> The format of digestN is: <algo name>:\0<digest value>, the same used
>>>> for the file digest.
>>>
>>> Since the format is changing from the SHA-1 log format anyway ...
>>>
>>> How do people feel about the colon and null terminated string format for
>>> algorithm identifiers?
>>>
>>> The TCG standard enumerations are uint16_t, and there is a registry of
>>> hash algorithms.
>>>
>>> As a consuming parser, it feels nice to know it's always 2 bytes and not
>>> have to worry about a missing colon or a missing nul terminator risking
>>> a buffer overflow.
>>
>> There cannot be buffer overflow, because the length of each digest
>> field is known.
>>
>> Roberto
>>
>
> I was not referring to the digest, but the digest algorithm.
>
> I wanted opinions on the colon and null terminated string format for
> algorithm identifiers.
>
> The TCG standard log uses the TCG standard enumerations.  They're always
> exactly 2 bytes.  Parsing is trivial.

I have two concerns regarding this:

is there a standard way to convert TPM_ALG_ to strings, like a function
exposed by the TSS? If not, suppose that a parser uses openssl to verify
the integrity of event data, by calculating the digest. Then,
the parser should maintain an association table between TPM_ALG_
and a string (the string will be passed to EVP_get_digestbyname()).
When a new TPM algorithm is added to the TCG registry, all parsers
should be modified to update the association table. If IMA sends
a string, only the crypto subsystem has to be updated.

The format I'm proposing for event data digests would be the same
of that used for file digests. Should IMA provide a list with
two different formats?

Roberto


> If IMA uses strings, the attacker can send, e.g., sha1: and not null
> terminate it.  A careful parser can go a byte at a time until it reaches
> a maximum length - if you specify a maximum length.  But it is an attack
> surface.  Is there a corresponding advantage?
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Linux-ima-devel mailing list
> Linux-ima-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-ima-devel
>

WARNING: multiple messages have this Message-ID (diff)
From: roberto.sassu@huawei.com (Roberto Sassu)
To: linux-security-module@vger.kernel.org
Subject: [Linux-ima-devel] [PATCH 0/7] IMA: new parser for ima_restore_measurement_list()
Date: Wed, 24 May 2017 10:18:46 +0200	[thread overview]
Message-ID: <e7386c0d-332b-1d61-a927-ad9b9dcd1449@huawei.com> (raw)
In-Reply-To: <08bd9fcb-d3ba-e76e-928e-f569e8a4be74@linux.vnet.ibm.com>

On 5/23/2017 10:48 PM, Ken Goldman wrote:
> On 5/18/2017 5:38 AM, Roberto Sassu wrote:
>> On 5/17/2017 6:28 PM, Ken Goldman wrote:
>>> On 5/17/2017 3:25 AM, Roberto Sassu wrote:
>>>>
>>>> The format of digestN is: <algo name>:\0<digest value>, the same used
>>>> for the file digest.
>>>
>>> Since the format is changing from the SHA-1 log format anyway ...
>>>
>>> How do people feel about the colon and null terminated string format for
>>> algorithm identifiers?
>>>
>>> The TCG standard enumerations are uint16_t, and there is a registry of
>>> hash algorithms.
>>>
>>> As a consuming parser, it feels nice to know it's always 2 bytes and not
>>> have to worry about a missing colon or a missing nul terminator risking
>>> a buffer overflow.
>>
>> There cannot be buffer overflow, because the length of each digest
>> field is known.
>>
>> Roberto
>>
>
> I was not referring to the digest, but the digest algorithm.
>
> I wanted opinions on the colon and null terminated string format for
> algorithm identifiers.
>
> The TCG standard log uses the TCG standard enumerations.  They're always
> exactly 2 bytes.  Parsing is trivial.

I have two concerns regarding this:

is there a standard way to convert TPM_ALG_ to strings, like a function
exposed by the TSS? If not, suppose that a parser uses openssl to verify
the integrity of event data, by calculating the digest. Then,
the parser should maintain an association table between TPM_ALG_
and a string (the string will be passed to EVP_get_digestbyname()).
When a new TPM algorithm is added to the TCG registry, all parsers
should be modified to update the association table. If IMA sends
a string, only the crypto subsystem has to be updated.

The format I'm proposing for event data digests would be the same
of that used for file digests. Should IMA provide a list with
two different formats?

Roberto


> If IMA uses strings, the attacker can send, e.g., sha1: and not null
> terminate it.  A careful parser can go a byte at a time until it reaches
> a maximum length - if you specify a maximum length.  But it is an attack
> surface.  Is there a corresponding advantage?
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Linux-ima-devel mailing list
> Linux-ima-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-ima-devel
>
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2017-05-24  8:19 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-16 12:53 [PATCH 0/7] IMA: new parser for ima_restore_measurement_list() Roberto Sassu
2017-05-16 12:53 ` Roberto Sassu
2017-05-16 12:53 ` [PATCH 1/7] ima: introduce ima_parse_buf() Roberto Sassu
2017-05-16 12:53   ` Roberto Sassu
2017-06-05  5:54   ` [Linux-ima-devel] " Mimi Zohar
2017-06-05  5:54     ` Mimi Zohar
2017-05-16 12:53 ` [PATCH 2/7] ima: use ima_parse_buf() to parse measurements headers Roberto Sassu
2017-05-16 12:53   ` Roberto Sassu
2017-05-16 12:53 ` [PATCH 3/7] ima: use ima_parse_buf() to parse template data Roberto Sassu
2017-05-16 12:53   ` Roberto Sassu
2017-05-16 12:53 ` [PATCH 4/7] ima: declare get_binary_runtime_size() as non-static Roberto Sassu
2017-05-16 12:53   ` Roberto Sassu
2017-05-16 12:53 ` [PATCH 5/7] ima: add securityfs interface to save a measurements list with kexec header Roberto Sassu
2017-05-16 12:53   ` Roberto Sassu
2017-06-05  6:04   ` [Linux-ima-devel] " Mimi Zohar
2017-06-05  6:04     ` Mimi Zohar
2017-06-06  8:49     ` Roberto Sassu
2017-06-06  8:49       ` Roberto Sassu
2017-06-06 10:56       ` Mimi Zohar
2017-06-06 10:56         ` Mimi Zohar
2017-06-06 12:45         ` Roberto Sassu
2017-06-06 12:45           ` Roberto Sassu
2017-06-06 13:23           ` Mimi Zohar
2017-06-06 13:23             ` Mimi Zohar
2017-06-13  7:27             ` Roberto Sassu
2017-06-13  7:27               ` Roberto Sassu
2017-06-13 12:09               ` Mimi Zohar
2017-06-13 12:09                 ` Mimi Zohar
2017-06-13 12:37                 ` Roberto Sassu
2017-06-13 12:37                   ` Roberto Sassu
2017-06-06  9:13     ` [Linux-ima-devel] " Roberto Sassu
2017-06-06  9:13       ` Roberto Sassu
2017-06-06 11:33       ` Mimi Zohar
2017-06-06 11:33         ` Mimi Zohar
2017-05-16 12:53 ` [PATCH 6/7] ima: add securityfs interface to restore a measurements list Roberto Sassu
2017-05-16 12:53   ` Roberto Sassu
2017-06-05  5:56   ` [Linux-ima-devel] " Mimi Zohar
2017-06-05  5:56     ` Mimi Zohar
2017-05-16 12:53 ` [PATCH 7/7] ima: fix get_binary_runtime_size() Roberto Sassu
2017-05-16 12:53   ` Roberto Sassu
2017-05-16 19:00 ` [Linux-ima-devel] [PATCH 0/7] IMA: new parser for ima_restore_measurement_list() Ken Goldman
2017-05-16 19:00   ` Ken Goldman
2017-05-17  7:25   ` Roberto Sassu
2017-05-17  7:25     ` Roberto Sassu
2017-05-17 16:28     ` Ken Goldman
2017-05-17 16:28       ` Ken Goldman
2017-05-18  9:38       ` Roberto Sassu
2017-05-18  9:38         ` Roberto Sassu
2017-05-23 20:48         ` Ken Goldman
2017-05-23 20:48           ` Ken Goldman
2017-05-24  8:18           ` Roberto Sassu [this message]
2017-05-24  8:18             ` Roberto Sassu
2017-05-23 21:00         ` Ken Goldman
2017-05-23 21:00           ` Ken Goldman

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=e7386c0d-332b-1d61-a927-ad9b9dcd1449@huawei.com \
    --to=roberto.sassu@huawei.com \
    --cc=kgold@linux.vnet.ibm.com \
    --cc=linux-ima-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    /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.