lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1384864428-3895-1-git-send-email-roberto.sassu@polito.it>
Date:	Tue, 19 Nov 2013 13:33:39 +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: [PATCH-v2 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 'target-subj') 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|target-subj
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 file execution 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.



=== UPDATE ===

This new version of the patch set includes two important updates in respect
to the previous one. First, newly created templates are added to the created
linked list (whose head is the first element of the 'defined_templates' array)
to avoid duplicates. Second, instead of storing the template name or format
strings in the IMA policy structure (ima_rule_entry), this patch set records
directly the pointer to newly created template descriptors obtained from
the function ima_get_template_desc(). Callers of ima_alloc_init_template()
determine the template to be used to produce a new measurement entry
(the default template or that stored in a matched policy rule) and supply
it as argument to this function. The benefit of the latter change is that
template lookup operations happen only during IMA initialization or the
loading of a custom policy (before, lookup was done each time an event matches
a rule with a custom template to translate the name or format string into
a template descriptor).

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: added ima_template and ima_template_fmt new policy options
  ima: pass template descriptor to ima_alloc_init_template()
  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        |  3 +-
 security/integrity/ima/ima_main.c        |  6 ++-
 security/integrity/ima/ima_policy.c      | 37 ++++++++++++++++-
 security/integrity/ima/ima_template.c    | 70 ++++++++++++++++++++++++++++++--
 8 files changed, 147 insertions(+), 30 deletions(-)

-- 
1.8.1.4


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ