Re: [Linux-ima-devel] [Linux-ima-user] Query about evmctl and hash algo

[Roberto S. <rob...@po...>]

Il 3/13/2013 10:16 PM, Mimi Zohar ha scritto:
> On Wed, 2013-03-13 at 21:42 +0100, Roberto Sassu wrote:
>> Il 3/13/2013 7:11 PM, Mimi Zohar ha scritto:
>>> On Wed, 2013-03-13 at 13:26 -0400, Vivek Goyal wrote:
>>>> On Wed, Mar 13, 2013 at 11:34:28AM -0400, Vivek Goyal wrote:
>>>>> Hi Dmitry,
>>>>>
>>>>> I used evmctl to sign an executable. I used an x.509 cert. I generated
>>>>> cert and specified to use -sha256 algorithm.
>>>>>
>>>>> But I noticed that evmctl ignores x.509 values and by default calculates
>>>>> sha1 hash.
>>>>>
>>>>> I thought we should honor x.509 certificate and use the hashing algorithm
>>>>> as specified in the cert. What do you think?
>>>>>
>>>>
>>>> Or may be I have misunderstood it and x.509 does not impose the type
>>>> of hash algorithm that should be used for signing. And user is free to
>>>> use any hash algorithm.
>>>
>>> Vivek, we definitely want to be able to collect, store, and appraise
>>> files based on the signature hash algorithm.  For now, the kernel only
>>> supports sha1.  Dmitry has some kernel patches in his
>>> linux-digsig/#working branch, which are not yet quite ready to be posted
>>> or upstreamed.
>>>
>>> Before being able to support hashes larger than md5/sha1, we also need
>>> to modify the existing 'ima' template.  Otherwise we would need to hash
>>> the file twice - once for the measurement list and again based on the
>>> signature.  I've pushed out some patches yesterday, which also are not
>>> quite ready for review, to the "next-multiple-template" branch.  These
>>> patches are based on the 'template' patches written 3+ years ago, but
>>> were never upstreamed.  Below is the patch description from the first
>>> patch.
>>>
>>>       The original 'ima' template data includes just the file hash and
>>>       filename.  The hash algorithm size is limited to 20 bytes (md5/sha1).
>>>       The filename is a null terminated string, limited to 255 characters.
>>>       To overcome these limitations, and provide additional file metadata,
>>>       this patch set introduces multiple templates of variable length sizes.
>>>       Future patches will address TPM v2.0 changes.
>>>
>>>       This first patch adds the template data length to the
>>>       binary_runtime_measurements list.  As new templates are defined,
>>>       userspace will continue being able to verify the measurement list
>>>       against the PCR value, yet skip unknown templates.
>>>
>>>       For the patches to be bisect safe and not break userspace, defer
>>>       adding the ability to change the template, until the 'ima-ng' template
>>>       definition is complete.
>>>
>>> The patches to support larger hashes, will be included prior, to the
>>> last patch in this patch set, which changes the default 'ima' template
>>> to 'ima-ng' template and adds a boot command line option for backwards
>>> compatibility.  For a better understanding of what needs to be done,
>>> please refer to the individual patch descriptions.
>>>
>>
>> Hi Mimi, Vivek
>>
>> I'm following this mailing list and I noticed that there is some
>> activity about the IMA templates topic.
>>
>> I'm currently working in this area and I produced some patches that
>> introduce this functionality. They are completely different from
>> those that were developed some years ago. For example, now, in my
>> implementation, it is possible to define a template as a set of fields
>> separated by '|'. Also, there are template names that are associated
>> to a specific set of fields.
>>
>> Each field is defined by two functions: init() to populate data from
>> arguments passed to this function and show() to display that data in
>> ascii or in binary format so that IMA should not be aware of the format
>> but it only has to store the data.
>>
>> I will deliver these patches shortly.
>
> It sounds like a really interesting solution, that scales a lot better
> than what we originally had.  My concern is userspace (eg. trousers,
> openpts, etc) being able to parse this dynamic, variable measurement
> list definition.  I'm looking forward to seeing the patches!
>

Yes, that could be a problem. However, I think this solution eases the
task of adding support for multiple templates in userspace programs
as these applications should only implement a parser for each field
identifier and then, they are capable of inspecting a generic
measurement by retrieving the format contained in the measurement
itself.

Roberto Sassu


> thanks,
>
> Mimi
>