Date:	Thu,  7 Nov 2013 16:49:35 +0100
From:	Roberto Sassu <roberto.sassu@...ito.it>
To:	linux-security-module@...r.kernel.org
Cc:	linux-kernel@...r.kernel.org,
	linux-ima-devel@...ts.sourceforge.net, zohar@...ibm.com,
	d.kasatkin@...sung.com, james.l.morris@...cle.com,
	Roberto Sassu <roberto.sassu@...ito.it>
Subject: [RFC][PATCH 0/6] ima: support per-measurement templates

Hi everyone

one functionality that is missing in the new template management mechanism
is the possibility to specify a custom template format per-measurement entry.
Until now, once the template is determined from the kernel configuration
or from the kernel command line parameters 'ima_template' and ima_template_fmt',
this template is used to generate all measurements entries in the list.

However, it is desirable to differentiate information included in measurement
entries depending on the event type from which they are generated. To explain
the usefulness of the proposed modification, I'll make an example.

One feature coming soon is the addition of new template fields that represent
LSM labels applied either to the current process and to the inode being
measured. However, these information are not enough to capture the mapping
between the executable code loaded for a given subject. Indeed, for example
in SELinux, a type transition may occur if the type of the current process
and the type of the inode being executed are matched in a 'type_transition'
policy rule. In this case, the code should be mapped not to the label of the
current process but instead to the label in the credentials (stored in the
'linux_binprm' structure) being installed during the execution of the execve()
system call.

To correctly perform the mapping code - LSM label, it is needed to introduce
a new template field to represent the LSM label in the 'linux_binprm' structure
(e.g. with identifier 'bprm-label') and a new IMA policy action
(e.g. measure_log_all) to record a measurement for every event that match
rule criteria, although the accessed inode has already been measured. Then,
assuming that the format of the default template is "d-ng|n-ng|subj|obj"
(digest + hash algo, long event name, subject LSM label, object LSM label),
the policy to capture the mapping should be:

---
measure_log_all func=BPRM_CHECK mask=MAY_EXEC \
    ima_template_fmt=d-ng|n-ng|subj|obj|lsm-label
measure_log_all func=FILE_MMAP mask=MAY_EXEC
---

In the first rule, the default template is overridden with a template that
contains the label stored in the 'linux_binprm' structure. Thus, in the
resulting measurements list, all entries that record the execution of binaries
will include the additional template field, while those generated from the
mapping into memory of shared libraries will contain only fields listed
in the default template.

Roberto Sassu


Roberto Sassu (6):
  ima: connect defined IMA templates through a linked list
  ima: added new template helper lookup_template_desc_by_fmt()
  ima: added ima_get_template_desc() for templates dynamic registration
  ima: replace ima_template_desc_current() with ima_get_template_desc()
  ima: added ima_template and ima_template_fmt new policy options
  ima: use custom template obtained from a matched policy rule

 Documentation/ABI/testing/ima_policy     |  6 ++-
 Documentation/security/IMA-templates.txt | 19 +++++----
 security/integrity/ima/ima.h             | 14 ++++---
 security/integrity/ima/ima_api.c         | 22 +++++++----
 security/integrity/ima/ima_init.c        |  2 +-
 security/integrity/ima/ima_main.c        | 13 +++++--
 security/integrity/ima/ima_policy.c      | 52 ++++++++++++++++++++++++-
 security/integrity/ima/ima_template.c    | 67 +++++++++++++++++++++++++++++---
 8 files changed, 161 insertions(+), 34 deletions(-)

-- 
1.8.1.4


Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (2061 bytes)

Powered by blists - more mailing lists