ima_template and ima_template_format - supported and legal values

ima_template and ima_template_format - supported and legal values

[Ken Goldman]

I have two questions.

~~

I'm writing an informal specification for the IMA event log.

I'd like to include a chart noting which kernel version first supported 
various options.  I.e. the IMA templates (ima, ima-ng, ima-sig), and the
ima_template_format directive and its various values.

Does anyone have any contribution?

In return, I'll send the document to anyone who asks.

~~

I'm writing a library of useful IMA event log parsing functions.

Are all format combinations legal?  It's not enough to look at today's 
code, because the code can change.

For example, ima_template_format="sig" doesn't make sense, because
it's a signature over a missing file data hash, but it's accepted.
The log it creates is odd, though, with just two entries.

Re: ima_template and ima_template_format - supported and legal values

[Mimi Zohar]

On Fri, 2018-10-05 at 18:53 -0400, Ken Goldman wrote:
> I have two questions.
> 
> I'm writing an informal specification for the IMA event log.
> 
> I'd like to include a chart noting which kernel version first supported 
> various options.  I.e. the IMA templates (ima, ima-ng, ima-sig), and the
> ima_template_format directive and its various values.

All of this information is readily available in the git repo.  There's
a commit number associated with every line of code.  Use "git blame
<pathname>" to associate a line of code with a specific commit number.

[1] Commit 3323eec921ef ("integrity: IMA as an integrity service
provider")
[2] Commit c2426d2ad502 ("ima: added support for new kernel cmdline
parameter ima_template_fmt")
[3] Commit 3ce1217d6cd5 ("ima: define template fields library and new
helpers")
[4] Commit bcbc9b0cf6d8 ("ima: extend the measurement list to include
the file signature")
[5] Commit 4d7aeee73f53 ("ima: define new template ima-ng and template
fields d-ng and n-ng")

To determine when a commit was upstreamed, add linux-stable as a
remote branch and execute "git branch -r --contains <commit number>".
 In this case, all of the existing template fields and template
formats were upstreamed in Linux 3.13.

linux-2.6:  ima			[1]
linux-3.13: ima-ng		[2, 5]
linux-3.13:
ima-sig		[4]
		
linux-3.13: 'n', 'd'		[3]
linux-3.13: 'n-ng', 'd-ng'	[5]
linux-3.13: 'sig'		[4]


> I'm writing a library of useful IMA event log parsing functions.
> 
> Are all format combinations legal?  It's not enough to look at today's 
> code, because the code can change.
> 
> For example, ima_template_format="sig" doesn't make sense, because
> it's a signature over a missing file data hash, but it's accepted.
> The log it creates is odd, though, with just two entries.

The parser should be able to handle all custom templates, whether or
not it makes sense.  Leaving out the digest (d, d-ng) or the filename
(n, n-ng) also doesn't make sense.  Deciding whether the measurement
list makes sense and/or addressing other measurement list issues, is
left up to userspace applications, such as the attestation server.

Please note that although the old 'd' digest or the 'n' filename
fields are defined, their use should be limited to the 'ima' template.

Mimi

Re: ima_template and ima_template_format - supported and legal values

[Mimi Zohar]

On Fri, 2018-10-05 at 18:53 -0400, Ken Goldman wrote:
> I have two questions.
> 
> I'm writing an informal specification for the IMA event log.
> 
> I'd like to include a chart noting which kernel version first supported 
> various options.  I.e. the IMA templates (ima, ima-ng, ima-sig), and the
> ima_template_format directive and its various values.

All of this information is readily available in the git repo.  There's
a commit number associated with every line of code.  Use "git blame
<pathname>" to associate a line of code with a specific commit number.

[1] Commit 3323eec921ef ("integrity: IMA as an integrity service
provider")
[2] Commit c2426d2ad502 ("ima: added support for new kernel cmdline
parameter ima_template_fmt")
[3] Commit 3ce1217d6cd5 ("ima: define template fields library and new
helpers")
[4] Commit bcbc9b0cf6d8 ("ima: extend the measurement list to include
the file signature")
[5] Commit 4d7aeee73f53 ("ima: define new template ima-ng and template
fields d-ng and n-ng")

To determine when a commit was upstreamed, add linux-stable as a
remote branch and execute "git branch -r --contains <commit number>".
 In this case, all of the existing template fields and template
formats were upstreamed in Linux 3.13.

linux-2.6:  ima			[1]
linux-3.13: ima-ng		[2, 5]
linux-3.13:
ima-sig		[4]
		
linux-3.13: 'n', 'd'		[3]
linux-3.13: 'n-ng', 'd-ng'	[5]
linux-3.13: 'sig'		[4]


> I'm writing a library of useful IMA event log parsing functions.
> 
> Are all format combinations legal?  It's not enough to look at today's 
> code, because the code can change.
> 
> For example, ima_template_format="sig" doesn't make sense, because
> it's a signature over a missing file data hash, but it's accepted.
> The log it creates is odd, though, with just two entries.

The parser should be able to handle all custom templates, whether or
not it makes sense.  Leaving out the digest (d, d-ng) or the filename
(n, n-ng) also doesn't make sense.  Deciding whether the measurement
list makes sense and/or addressing other measurement list issues, is
left up to userspace applications, such as the attestation server.

Please note that although the old 'd' digest or the 'n' filename
fields are defined, their use should be limited to the 'ima' template.

Mimi