Linux-Integrity Archive on lore.kernel.org
 help / Atom feed
* [DISCUSSION] IMA measurement log format
@ 2018-12-28 19:25 Jordan Hand
  2018-12-30  4:19 ` Mimi Zohar
  0 siblings, 1 reply; 2+ messages in thread
From: Jordan Hand @ 2018-12-28 19:25 UTC (permalink / raw)
  To: linux-integrity

Hi folks,

I have a question about the format of the IMA measurement log (/sys/kernel/security/ima/binary_runtime_measurements).

The current IMA format uses the following structure:

struct ima_template_entry {
	int pcr;
	u8 digest[TPM_DIGEST_SIZE];	/* sha1 or md5 measurement hash */
	struct ima_template_desc *template_desc; /* template descriptor */
	u32 template_data_len;
	struct ima_field_data template_data[0];	/* template related data */
};

My question is, why does the IMA log not use the same log format that is used for PCR events in the TCG EFI spec? This would allow the same parser to be used for binary_bios_measurements and binary_runtime_measurements, while still maintaining all information captured by the current template format simply as event data.

Here is the EFI structure that is logged for each event in binary_bios_measurements (it is similar the structure used by IMA but different enough to require different parsing).

typedef struct {
    TCG_PCRINDEX PCRIndex;
    TCG_EVENTTYPE EventType;
    TCG_DIGEST digest;
    UINT32 EventSize;
    UINT8 Event[1];
} TCG_PCR_EVENT;

From the TCG EFI Spec: https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-rev13-160330final.pdf
Note the above structure is for the TPM1.2 speficiation. There is a slightly different crypto-agile TCG_PCR_EVENT2 structure for TPM2.0. 

I feel that, when possible, it is best that the kernel keep continuity with other components which will be measuring events into the TPM for ease of parsing when these logs are used for attestation.

I understand these may not be trivial changes (and log format changes may break existing applications) but I would like to get some thoughts on why some of these decisions were made and possible ways to get more continuity in Linux system attestation moving forward.

Thanks!
Jordan



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [DISCUSSION] IMA measurement log format
  2018-12-28 19:25 [DISCUSSION] IMA measurement log format Jordan Hand
@ 2018-12-30  4:19 ` Mimi Zohar
  0 siblings, 0 replies; 2+ messages in thread
From: Mimi Zohar @ 2018-12-30  4:19 UTC (permalink / raw)
  To: Jordan Hand, linux-integrity
  Cc: Wiseman, Monty (GE Global Research, US), David Safford

[Cc'ing Monty Wiseman and David Safford)

Hi Jordan,

On Fri, 2018-12-28 at 19:25 +0000, Jordan Hand wrote:
> Hi folks,
> 
> I have a question about the format of the IMA measurement log
> (/sys/kernel/security/ima/binary_runtime_measurements).
> 
> The current IMA format uses the following structure:
> 
> struct ima_template_entry {
> 	int pcr;
> 	u8 digest[TPM_DIGEST_SIZE];	/* sha1 or md5 measurement hash */
> 	struct ima_template_desc *template_desc; /* template descriptor */
> 	u32 template_data_len;
> 	struct ima_field_data template_data[0];	/* template related data */
> };
> 
> My question is, why does the IMA log not use the same log format
> that is used for PCR events in the TCG EFI spec? This would allow
> the same parser to be used for binary_bios_measurements and
> binary_runtime_measurements, while still maintaining all information
> captured by the current template format simply as event data.
> 
> Here is the EFI structure that is logged for each event in
> binary_bios_measurements (it is similar the structure used by IMA
> but different enough to require different parsing).
> 
> typedef struct {
>     TCG_PCRINDEX PCRIndex;
>     TCG_EVENTTYPE EventType;
>     TCG_DIGEST digest;
>     UINT32 EventSize;
>     UINT8 Event[1];
> } TCG_PCR_EVENT;
> 
> From the TCG EFI Spec: https://trustedcomputinggroup.org/wp-content/
> uploads/EFI-Protocol-Specification-rev13-160330final.pdf
> Note the above structure is for the TPM1.2 speficiation. There is a
> slightly different crypto-agile TCG_PCR_EVENT2 structure for
> TPM2.0. 
> 
> I feel that, when possible, it is best that the kernel keep
> continuity with other components which will be measuring events into
> the TPM for ease of parsing when these logs are used for
> attestation.
> 
> I understand these may not be trivial changes (and log format
> changes may break existing applications) but I would like to get
> some thoughts on why some of these decisions were made and possible
> ways to get more continuity in Linux system attestation moving
> forward.

Although IMA was only upstreamed in 2009, some of the code dates back
to the early 2000's.  The first paper "Design and implementation of a
TCG-based integrity measurement architecture" was published in Usenix
2004.

You should probably look at Monty Wiseman's and David Safford's LSS-NA 
2018 talk titled "A Canonical Event Log Structure for IMA".  Slides
and recordings of LSS-NA 2018 can be found on the LF website.

Defining a new log format is definitely non trivial and may not break
existing userspace applications.

Mimi


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, back to index

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-12-28 19:25 [DISCUSSION] IMA measurement log format Jordan Hand
2018-12-30  4:19 ` Mimi Zohar

Linux-Integrity Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-integrity/0 linux-integrity/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-integrity linux-integrity/ https://lore.kernel.org/linux-integrity \
		linux-integrity@vger.kernel.org linux-integrity@archiver.kernel.org
	public-inbox-index linux-integrity


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-integrity


AGPL code for this site: git clone https://public-inbox.org/ public-inbox