Spec needed for ima-modsig template

Spec needed for ima-modsig template

[Ken Goldman]

I'm trying to document the ima-modsig template and then write aparser. 
Can anyone help me complete it?

1 - What the implementation does today is interesting.  Even betterwould 
be what the implementation is permitted to do so that theparser will 
handle future changes.

2 - My understanding so far:

     ima-modsig        is        d-ng | n-ng | sig | d-modsig |modsig

     where (both have a prepended uint32_t length)

     d-modsig            is    d-ng, filedata hash, omitting the 
appended modsig signature
     modsig                is     pkcs7DER, appended signature

My immediate issue is that the d-modsig should be a length + 
hashalgorithm + file data hash.  However, the length in my sample log 
issometimes zero, which I did not expect.

I.e., it it legal for an ima-modsig template to contain an emptyd-modsig 
item?

Can the modsig item also be empty?

Re: Spec needed for ima-modsig template

[Mimi Zohar]

On Thu, 2020-01-02 at 15:10 -0500, Ken Goldman wrote:
> I'm trying to document the ima-modsig template and then write aparser. 
> Can anyone help me complete it?
> 
> 1 - What the implementation does today is interesting.  Even betterwould 
> be what the implementation is permitted to do so that theparser will 
> handle future changes.
> 
> 2 - My understanding so far:
> 
>      ima-modsig        is        d-ng | n-ng | sig | d-modsig |modsig
> 
>      where (both have a prepended uint32_t length)
> 
>      d-modsig            is    d-ng, filedata hash, omitting the 
> appended modsig signature
>      modsig                is     pkcs7DER, appended signature
> 
> My immediate issue is that the d-modsig should be a length + 
> hashalgorithm + file data hash.  However, the length in my sample log 
> issometimes zero, which I did not expect.
> 
> I.e., it it legal for an ima-modsig template to contain an emptyd-modsig 
> item?
> 
> Can the modsig item also be empty?

Like the "sig" field in the "ima-sig" template, both the "d-modsig"
and "modsig" fields in the "ima-modsig" template may be empty.

Mimi

Re: Spec needed for ima-modsig template

[Ken Goldman]

On 1/2/2020 3:25 PM, Mimi Zohar wrote:
> On Thu, 2020-01-02 at 15:10 -0500, Ken Goldman wrote:
>> I'm trying to document the ima-modsig template and then write aparser.
>> Can anyone help me complete it?
>>
>> 1 - What the implementation does today is interesting.  Even betterwould
>> be what the implementation is permitted to do so that theparser will
>> handle future changes.
>>
>> 2 - My understanding so far:
>>
>>       ima-modsig        is        d-ng | n-ng | sig | d-modsig |modsig
>>
>>       where (both have a prepended uint32_t length)
>>
>>       d-modsig            is    d-ng, filedata hash, omitting the
>> appended modsig signature
>>       modsig                is     pkcs7DER, appended signature
>>
>> My immediate issue is that the d-modsig should be a length +
>> hashalgorithm + file data hash.  However, the length in my sample log
>> issometimes zero, which I did not expect.
>>
>> I.e., it it legal for an ima-modsig template to contain an emptyd-modsig
>> item?
>>
>> Can the modsig item also be empty?
> 
> Like the "sig" field in the "ima-sig" template, both the "d-modsig"
> and "modsig" fields in the "ima-modsig" template may be empty.
> 

I understand sig being empty is the file isn't signed.  Same with 
modsig.  The verifier could flag that.

However, d-modsig is a hash.  How should a parser interpret a missing 
[file data] hash?  Under what conditions would that be legal / illegal / 
something to flag to an admin UI?

Re: Spec needed for ima-modsig template

[Mimi Zohar]

On Thu, 2020-01-02 at 17:24 -0500, Ken Goldman wrote:
> On 1/2/2020 3:25 PM, Mimi Zohar wrote:
> > On Thu, 2020-01-02 at 15:10 -0500, Ken Goldman wrote:
> >> I'm trying to document the ima-modsig template and then write aparser.
> >> Can anyone help me complete it?
> >>
> >> 1 - What the implementation does today is interesting.  Even betterwould
> >> be what the implementation is permitted to do so that theparser will
> >> handle future changes.
> >>
> >> 2 - My understanding so far:
> >>
> >>       ima-modsig        is        d-ng | n-ng | sig | d-modsig |modsig
> >>
> >>       where (both have a prepended uint32_t length)
> >>
> >>       d-modsig            is    d-ng, filedata hash, omitting the
> >> appended modsig signature
> >>       modsig                is     pkcs7DER, appended signature
> >>
> >> My immediate issue is that the d-modsig should be a length +
> >> hashalgorithm + file data hash.  However, the length in my sample log
> >> issometimes zero, which I did not expect.
> >>
> >> I.e., it it legal for an ima-modsig template to contain an emptyd-modsig
> >> item?
> >>
> >> Can the modsig item also be empty?
> > 
> > Like the "sig" field in the "ima-sig" template, both the "d-modsig"
> > and "modsig" fields in the "ima-modsig" template may be empty.
> > 
> 
> I understand sig being empty is the file isn't signed.  Same with 
> modsig.  The verifier could flag that.
> 
> However, d-modsig is a hash.  How should a parser interpret a missing 
> [file data] hash?  Under what conditions would that be legal / illegal / 
> something to flag to an admin UI?

The "d-modsig" is the hash of the file without the appended signature.
 That hash is needed to verify the appended signature.  If there isn't
an appended signature, then there would be no reason for "d-modsig".

Mimi

Re: Spec needed for ima-modsig template

[Ken Goldman]

On 1/2/2020 6:22 PM, Mimi Zohar wrote:
>> However, d-modsig is a hash.  How should a parser interpret a missing
>> [file data] hash?  Under what conditions would that be legal / illegal /
>> something to flag to an admin UI?
> The "d-modsig" is the hash of the file without the appended signature.
>   That hash is needed to verify the appended signature.  If there isn't
> an appended signature, then there would be no reason for "d-modsig".

I'd like to make the leap from "no reason to" to what is permissible, 
what a verifier would treat as legal or an error case.

E.g., should the IMA log specification say:

If the sig length is zero, the d-modsig length MUST be zero.

Or might it be a MAY, and then state

If the signature length is zero and the d-modsig length is non-zero,
then the contents MUST be the same as the d-ng value.

What if the template has no 'd-ng', but it has a d-modsig?

What happens if the template has no 'sig'.  I.e. the sig
is absent, then ... perhaps absent is the same as length zero?

Would we enforce that the d-ng hash algorithm MUST be the same as
that of the d-modsig, or could they be different?

What if there are two 'sig' fields, one is zero and the other is not.

~~

While the above are clearly not the normal case:

1 - An attacker can use a custom IMA template to find a vulnerability in 
the IMA implementation, or

2 - An attacker could send a malformed log to a verifier.  To the 
verifier, the received IMA log is unvalidated input, so the parser has 
to be fastidious.

Spec needed for ima-buf template

[Ken Goldman]

In the ima-buf template, I sense that the n-ng file names are not 
actually file names, but (sort of) ASCII enums.  Is that right?

1 - I've identified a few that mean the 'buf' contents are DER encoded 
X509 certificates.  Are there others in this group?

.builtin_trusted_keys
.ima

2 - There is evidently a 'file name' that indicates that the contents 
are the boot command line.  Would it be '/proc/cmdline' or something else?

Could the name vary with the kernel version or distro?

What would be a maximum length for this buf beyond which the verifier 
should report an error?

3 - What other file names could a verifier expect?

4 - What happens if there is a 'buf' but not an 'n-ng'?  For
example, the custom template "d-ng | buf".  Or if there is an n-ng but 
the file name length is zero?

Is this an error?  If not, how would the contents of buf be interpreted 
without a file name?

5 - Are the file names for this template fixed today, or could there be 
more added in the future?  If more could be added, is there the concept 
of 'critical' names that a verifier must understand or reject and 
non-critical that the verifier could safely ignore?

Spec needed for ima-buf template - missing hash algorithm

[Ken Goldman]

Another question about the ima-buf template.  I discovered a log where 
the filename is blacklisted-hash.  It appears to be followed by 32-bytes 
that could be a hash.

Normally, hashes have an ASCII algorithm, a : and nul terminated string. 
  The one in my log omits the algorithm.  There are just 32 bytes.

1 - Is this a malformed log?

2 - Is the algorithm picked up from the d-ng field?

3 - If (2), what happens if there is a custom template like 'n-ng|buf' 
and there is no d-ng to pick up the hash algorithm from?

Re: Spec needed for ima-modsig template

[Mimi Zohar]

On Fri, 2020-01-03 at 13:27 -0500, Ken Goldman wrote:
> On 1/2/2020 6:22 PM, Mimi Zohar wrote:
> >> However, d-modsig is a hash.  How should a parser interpret a missing
> >> [file data] hash?  Under what conditions would that be legal / illegal /
> >> something to flag to an admin UI?
> > The "d-modsig" is the hash of the file without the appended signature.
> >   That hash is needed to verify the appended signature.  If there isn't
> > an appended signature, then there would be no reason for "d-modsig".
> 
> I'd like to make the leap from "no reason to" to what is permissible, 
> what a verifier would treat as legal or an error case.
> 
> E.g., should the IMA log specification say:
> 
> If the sig length is zero, the d-modsig length MUST be zero.
> 
> Or might it be a MAY, and then state
> 
> If the signature length is zero and the d-modsig length is non-zero,
> then the contents MUST be the same as the d-ng value.
> 
> What if the template has no 'd-ng', but it has a d-modsig?
> 
> What happens if the template has no 'sig'.  I.e. the sig
> is absent, then ... perhaps absent is the same as length zero?
> 
> Would we enforce that the d-ng hash algorithm MUST be the same as
> that of the d-modsig, or could they be different?
> 
> What if there are two 'sig' fields, one is zero and the other is not.
> 
> ~~
> 
> While the above are clearly not the normal case:
> 
> 1 - An attacker can use a custom IMA template to find a vulnerability in 
> the IMA implementation, or
> 
> 2 - An attacker could send a malformed log to a verifier.  To the 
> verifier, the received IMA log is unvalidated input, so the parser has 
> to be fastidious.

The "ima-modsig" template may include the "sig" and/or the "modsig"
fields.  As the "d-modsig" and "modsig" are tied together, either both
are defined or neither are defined.  The file hash ("d-ng") must
always exist.  The "sig" and "modsig" hash algorithms are independent
of each other.  They might or might not be the same.

Mimi

Re: Spec needed for ima-modsig template

[Ken Goldman]

On 1/4/2020 6:32 PM, Mimi Zohar wrote:
> The "ima-modsig" template may include the "sig" and/or the "modsig"
> fields.  As the "d-modsig" and "modsig" are tied together, either both
> are defined or neither are defined.  The file hash ("d-ng") must
> always exist.
That's clear for the predefined (is there a formal term for them?) 
templates.  How would this be specified when IMA permits custom templates?

E.g., I can create a template 'modsig', I have the signature but not the 
file data hash.  I can create a template 'd-modsig' that has the file
data hash but no signature.

With custom templates, the attacker can create any IMA log, and the 
parser has to handle it.

Note:  When you say "either both are defined or neither is defined", 
this may be enforced by the official IMA code.  However, the attacker is 
free to modify the IMA code to send any log it likes.  The parser has to 
know what to do.

That is, an event log specification (which I'm trying to write) has to 
state precisely that the dependencies are and what should be rejected. 
For example, it might say (if this is corrct):

1 - If d-modsig is present, modsig MUST be present.  Else error.
2 - If modsig is present, d-modsig MUST be present.
3 - If ???, d-ng MUST be present.

Re: Spec needed for ima-modsig template

[Mimi Zohar]

[Cc'ing Roberto]

On Mon, 2020-01-06 at 09:27 -0500, Ken Goldman wrote:
> On 1/4/2020 6:32 PM, Mimi Zohar wrote:
> > The "ima-modsig" template may include the "sig" and/or the "modsig"
> > fields.  As the "d-modsig" and "modsig" are tied together, either both
> > are defined or neither are defined.  The file hash ("d-ng") must
> > always exist.
> That's clear for the predefined (is there a formal term for them?) 
> templates.  How would this be specified when IMA permits custom templates?

"predefined" is fine, or "builtin".

> 
> E.g., I can create a template 'modsig', I have the signature but not the 
> file data hash.  I can create a template 'd-modsig' that has the file
> data hash but no signature.

That should be flagged as an error.

> 
> With custom templates, the attacker can create any IMA log, and the 
> parser has to handle it.
> 
> Note:  When you say "either both are defined or neither is defined", 
> this may be enforced by the official IMA code.  However, the attacker is 
> free to modify the IMA code to send any log it likes.  The parser has to 
> know what to do.

An attacker shouldn't be able to spoof the PCR quote.  As previously
discussed, the verifier should first walk the measurement list
calculating the PCR values.  Only if the PCRs match, should the
verifier attempt to parse the individual template data records.

> 
> That is, an event log specification (which I'm trying to write) has to 
> state precisely that the dependencies are and what should be rejected. 
> For example, it might say (if this is corrct):
> 
> 1 - If d-modsig is present, modsig MUST be present.  Else error.
> 2 - If modsig is present, d-modsig MUST be present.

Yes

> 3 - If ???, d-ng MUST be present.

Templates were designed to be extensible, allowing new fields to be
defined and combined.  I can't say definitively that there will never
be a case when the "d-ng" field isn't needed, but at least for the
moment that is the case.  Perhaps with IMA fs-verity support, only a
digest and signature, based on the merkle tree file hash will be
needed.

Mimi

Re: Spec needed for ima-modsig template

[Ken Goldman]

On 1/4/2020 6:32 PM, Mimi Zohar wrote:
> The "sig" and "modsig" hash algorithms are independent
> of each other.  They might or might not be the same.

My question was about the d-modsig hash algorithm. Should the spec say:

1 - If d-ng and d-modsig are both present, the hash algorithms MUST be 
the same.

I did have a question about the 'd-ng | sig | sig' template.  Is that an 
error or could a file be signed with e.g. both RSA-2048 and RSA-3072?

Etc.  You can see where I'm going - precise rules for an IMA log verifier.

Re: Spec needed for ima-modsig template

[Mimi Zohar]

On Mon, 2020-01-06 at 09:36 -0500, Ken Goldman wrote:
> On 1/4/2020 6:32 PM, Mimi Zohar wrote:
> > The "sig" and "modsig" hash algorithms are independent
> > of each other.  They might or might not be the same.
> 
> My question was about the d-modsig hash algorithm. Should the spec say:
> 
> 1 - If d-ng and d-modsig are both present, the hash algorithms MUST be 
> the same.

No, the hash algorithm does not need to be the same.  The "d-ng" hash
algorithm is based on the "sig" field, if present, and defaults to the
IMA default algorithm as specified in the Kconfig -
CONFIG_IMA_DEFAULT_HASH.  The appended signature ("sig" field), like
in the case of the kexec kernel image, might be a third party
signature.

> 
> I did have a question about the 'd-ng | sig | sig' template.  Is that an 
> error or could a file be signed with e.g. both RSA-2048 and RSA-3072?
> 
> Etc.  You can see where I'm going - precise rules for an IMA log verifier.

The "sig" field is the original IMA signature, stored as an extended
attribute.  If/when IMA fs-verity support is added, that signature
would require defining new digest and signature field types.  A
template with two "sig" fields doesn't make sense.

Mimi

Re: Spec needed for ima-modsig template

[Ken Goldman]

On 1/6/2020 10:50 AM, Mimi Zohar wrote:
>> I did have a question about the 'd-ng | sig | sig' template.  Is that an
>> error or could a file be signed with e.g. both RSA-2048 and RSA-3072?
>>
>> Etc.  You can see where I'm going - precise rules for an IMA log verifier.
> The "sig" field is the original IMA signature, stored as an extended
> attribute.  If/when IMA fs-verity support is added, that signature
> would require defining new digest and signature field types.  A
> template with two "sig" fields doesn't make sense.

We cannot prevent an attacker from creating the custom template 'd-ng | 
sig | sig', nor can we prevent an attacker from sending such a log to a 
verifier.  Thus, we have to specify to a verifier what logs are valid 
and what logs should be rejected and flagged as an attack.

I.e., the verifier cannot assume that it will only receive logs that 
make sense.  A secure parser has to handle any cleverly malformed event log.

There are 8-9 different possible IMA log fields, and we have to assume 
the attacker will corrupt any or all of them.

Re: Spec needed for ima-modsig template

[Mimi Zohar]

On Mon, 2020-01-06 at 11:01 -0500, Ken Goldman wrote:
> On 1/6/2020 10:50 AM, Mimi Zohar wrote:
> >> I did have a question about the 'd-ng | sig | sig' template.  Is that an
> >> error or could a file be signed with e.g. both RSA-2048 and RSA-3072?
> >>
> >> Etc.  You can see where I'm going - precise rules for an IMA log verifier.
> > The "sig" field is the original IMA signature, stored as an extended
> > attribute.  If/when IMA fs-verity support is added, that signature
> > would require defining new digest and signature field types.  A
> > template with two "sig" fields doesn't make sense.
> 
> We cannot prevent an attacker from creating the custom template 'd-ng | 
> sig | sig', nor can we prevent an attacker from sending such a log to a 
> verifier.  Thus, we have to specify to a verifier what logs are valid 
> and what logs should be rejected and flagged as an attack.

There is only one security.ima extended attribute per file, at least
for the time being until IMA namespacing.  That would imply both "sig"
fields would have to be exactly the same.

Mimi

> 
> I.e., the verifier cannot assume that it will only receive logs that 
> make sense.  A secure parser has to handle any cleverly malformed event log.
> 
> There are 8-9 different possible IMA log fields, and we have to assume 
> the attacker will corrupt any or all of them.

RE: Spec needed for ima-modsig template

[Roberto Sassu]

> -----Original Message-----
> From: linux-integrity-owner@vger.kernel.org [mailto:linux-integrity-
> owner@vger.kernel.org] On Behalf Of Ken Goldman
> Sent: Monday, January 6, 2020 5:02 PM
> To: Mimi Zohar <zohar@linux.ibm.com>; Linux Integrity <linux-
> integrity@vger.kernel.org>; Ken Goldman <kgoldman@us.ibm.com>
> Subject: Re: Spec needed for ima-modsig template
> 
> On 1/6/2020 10:50 AM, Mimi Zohar wrote:
> >> I did have a question about the 'd-ng | sig | sig' template.  Is that an
> >> error or could a file be signed with e.g. both RSA-2048 and RSA-3072?
> >>
> >> Etc.  You can see where I'm going - precise rules for an IMA log verifier.
> > The "sig" field is the original IMA signature, stored as an extended
> > attribute.  If/when IMA fs-verity support is added, that signature
> > would require defining new digest and signature field types.  A
> > template with two "sig" fields doesn't make sense.
> 
> We cannot prevent an attacker from creating the custom template 'd-ng |
> sig | sig', nor can we prevent an attacker from sending such a log to a
> verifier.  Thus, we have to specify to a verifier what logs are valid
> and what logs should be rejected and flagged as an attack.

That's correct. A user can define a template with any field he wants.

Whether the template is acceptable, it depends on the verifier and on
his requirements. If the template contains all fields necessary for the
verification, that should be fine even if that template contains redundant
information. If there are inconsistencies, the verifier would simply return
an error as verification result. Defining a specification for which combinations
are legitimate would definitely help.


> There are 8-9 different possible IMA log fields, and we have to assume
> the attacker will corrupt any or all of them.

Template data is protected by the TPM. Any corruption can be detected
by comparing the quoted PCRs with the PCRs calculated from the template
digest.

What it remains to be done is to include the template name in the
calculation of the template digest.

Roberto

Re: Spec needed for ima-modsig template

[Ken Goldman]

On 1/7/2020 3:53 AM, Roberto Sassu wrote:
> Defining a specification for which combinations
> are legitimate would definitely help.

That's my goal.

>> There are 8-9 different possible IMA log fields, and we have to assume
>> the attacker will corrupt any or all of them.
> 
> Template data is protected by the TPM. Any corruption can be detected
> by comparing the quoted PCRs with the PCRs calculated from the template
> digest.

An attacker can create a custom template or even modify the IMA source 
so that the hashes and PCRs match.  Then they send the malformed log to 
the verifier to try to exploit a vulnerability.

E.g., the custom template 'd-ng|d-ng| ...' repeated 1,000,000,000 times.

> What it remains to be done is to include the template name in the
> calculation of the template digest.

There's a backward compatibility issue for old templates.  Is it 
feasible for new templates and new names - start creating tags and 
include them in the template data so they gets hashed?

RE: Spec needed for ima-modsig template

[Roberto Sassu]

> -----Original Message-----
> From: Ken Goldman [mailto:kgold@linux.ibm.com]
> Sent: Tuesday, January 7, 2020 4:41 PM
> To: Roberto Sassu <roberto.sassu@huawei.com>; Mimi Zohar
> <zohar@linux.ibm.com>; Linux Integrity <linux-integrity@vger.kernel.org>;
> Ken Goldman <kgoldman@us.ibm.com>; Silviu Vlasceanu
> <Silviu.Vlasceanu@huawei.com>
> Subject: Re: Spec needed for ima-modsig template
> 
> On 1/7/2020 3:53 AM, Roberto Sassu wrote:
> > Defining a specification for which combinations
> > are legitimate would definitely help.
> 
> That's my goal.
> 
> >> There are 8-9 different possible IMA log fields, and we have to assume
> >> the attacker will corrupt any or all of them.
> >
> > Template data is protected by the TPM. Any corruption can be detected
> > by comparing the quoted PCRs with the PCRs calculated from the
> template
> > digest.
> 
> An attacker can create a custom template or even modify the IMA source
> so that the hashes and PCRs match.  Then they send the malformed log to
> the verifier to try to exploit a vulnerability.

Modifying the IMA source can be excluded from possible attacks. The
modified kernel can be detected from the BIOS event log.

> E.g., the custom template 'd-ng|d-ng| ...' repeated 1,000,000,000 times.

Currently, the number of fields in a template format can be at most
IMA_TEMPLATE_NUM_FIELDS_MAX. I don't know if repeating the same
template field could introduce more risks.

> > What it remains to be done is to include the template name in the
> > calculation of the template digest.
> 
> There's a backward compatibility issue for old templates.  Is it
> feasible for new templates and new names - start creating tags and
> include them in the template data so they gets hashed?

I would suggest the following formats (without and with tags), to make
it easier for the parsers to distinguish between the old and the new format.

Assuming that the template format is 'field#0|...|field#N', the binary
format of each measurement entry without tags becomes:

<PCR><template digest><total len>\0<template name len><template name>
                                                                             <len#0><data#0>
                                                                             <len#N><data#N>

Template name can be one of the defined templates or 'field#0|...|field#N',
if the user specifies a custom format.

The binary format with tags becomes:

<PCR><template digest><total len>\0<tag#0><len#0><data#0>
                                                                             <tag#N><len#N><data#N>

Tag definition must be available for user space applications.

The \0 after <total len> allows parsers to distinguish between the old and
the new format. If there is no \0, parsers assume that <total len> is the
template name length of the old format.

For the new format, template digest is calculated on data after <total len>.

Roberto