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
next prev parent 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: linkBe 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.