IMA-templates.rst 4.6 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798
  1. =================================
  2. IMA Template Management Mechanism
  3. =================================
  4. Introduction
  5. ============
  6. The original ``ima`` template is fixed length, containing the filedata hash
  7. and pathname. The filedata hash is limited to 20 bytes (md5/sha1).
  8. The pathname is a null terminated string, limited to 255 characters.
  9. To overcome these limitations and to add additional file metadata, it is
  10. necessary to extend the current version of IMA by defining additional
  11. templates. For example, information that could be possibly reported are
  12. the inode UID/GID or the LSM labels either of the inode and of the process
  13. that is accessing it.
  14. However, the main problem to introduce this feature is that, each time
  15. a new template is defined, the functions that generate and display
  16. the measurements list would include the code for handling a new format
  17. and, thus, would significantly grow over the time.
  18. The proposed solution solves this problem by separating the template
  19. management from the remaining IMA code. The core of this solution is the
  20. definition of two new data structures: a template descriptor, to determine
  21. which information should be included in the measurement list; a template
  22. field, to generate and display data of a given type.
  23. Managing templates with these structures is very simple. To support
  24. a new data type, developers define the field identifier and implement
  25. two functions, init() and show(), respectively to generate and display
  26. measurement entries. Defining a new template descriptor requires
  27. specifying the template format (a string of field identifiers separated
  28. by the ``|`` character) through the ``ima_template_fmt`` kernel command line
  29. parameter. At boot time, IMA initializes the chosen template descriptor
  30. by translating the format into an array of template fields structures taken
  31. from the set of the supported ones.
  32. After the initialization step, IMA will call ``ima_alloc_init_template()``
  33. (new function defined within the patches for the new template management
  34. mechanism) to generate a new measurement entry by using the template
  35. descriptor chosen through the kernel configuration or through the newly
  36. introduced ``ima_template`` and ``ima_template_fmt`` kernel command line parameters.
  37. It is during this phase that the advantages of the new architecture are
  38. clearly shown: the latter function will not contain specific code to handle
  39. a given template but, instead, it simply calls the ``init()`` method of the template
  40. fields associated to the chosen template descriptor and store the result
  41. (pointer to allocated data and data length) in the measurement entry structure.
  42. The same mechanism is employed to display measurements entries.
  43. The functions ``ima[_ascii]_measurements_show()`` retrieve, for each entry,
  44. the template descriptor used to produce that entry and call the show()
  45. method for each item of the array of template fields structures.
  46. Supported Template Fields and Descriptors
  47. =========================================
  48. In the following, there is the list of supported template fields
  49. ``('<identifier>': description)``, that can be used to define new template
  50. descriptors by adding their identifier to the format string
  51. (support for more data types will be added later):
  52. - 'd': the digest of the event (i.e. the digest of a measured file),
  53. calculated with the SHA1 or MD5 hash algorithm;
  54. - 'n': the name of the event (i.e. the file name), with size up to 255 bytes;
  55. - 'd-ng': the digest of the event, calculated with an arbitrary hash
  56. algorithm (field format: [<hash algo>:]digest, where the digest
  57. prefix is shown only if the hash algorithm is not SHA1 or MD5);
  58. - 'd-modsig': the digest of the event without the appended modsig;
  59. - 'n-ng': the name of the event, without size limitations;
  60. - 'sig': the file signature;
  61. - 'modsig' the appended file signature;
  62. - 'buf': the buffer data that was used to generate the hash without size limitations;
  63. Below, there is the list of defined template descriptors:
  64. - "ima": its format is ``d|n``;
  65. - "ima-ng" (default): its format is ``d-ng|n-ng``;
  66. - "ima-sig": its format is ``d-ng|n-ng|sig``;
  67. - "ima-buf": its format is ``d-ng|n-ng|buf``;
  68. - "ima-modsig": its format is ``d-ng|n-ng|sig|d-modsig|modsig``;
  69. Use
  70. ===
  71. To specify the template descriptor to be used to generate measurement entries,
  72. currently the following methods are supported:
  73. - select a template descriptor among those supported in the kernel
  74. configuration (``ima-ng`` is the default choice);
  75. - specify a template descriptor name from the kernel command line through
  76. the ``ima_template=`` parameter;
  77. - register a new template descriptor with custom format through the kernel
  78. command line parameter ``ima_template_fmt=``.