From: Mimi Z. <zo...@li...> - 2013-03-13 21:16:53
|
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! thanks, Mimi |