Date:	Thu, 21 Nov 2013 09:11:26 -0500
From:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
To:	Roberto Sassu <roberto.sassu@...ito.it>
Cc:	linux-security-module@...r.kernel.org, zohar@...ibm.com,
	linux-kernel@...r.kernel.org, james.l.morris@...cle.com,
	linux-ima-devel@...ts.sourceforge.net
Subject: Re: [Linux-ima-devel] [PATCH-v2 0/6] ima: support per-measurement
 templates

On Tue, 2013-11-19 at 13:33 +0100, Roberto Sassu wrote:
> 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.

Adding support for multiple templates in the measurement list at the
same time is a good idea.  Extending the IMA policy to define a per rule
template definition is also a good idea.  However, the example to
illustrate these ideas is unnecessarily complex.  I think the complexity
is due to using fields, that haven't yet been defined, that are
themselves complex.  Please try and find a simpler example.

(Still reviewing the code.)

thanks,

Mimi

> 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(-)
> 
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing 
> conversations that shape the rapidly evolving mobile landscape. Sign up now. 
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> _______________________________________________
> Linux-ima-devel mailing list
> Linux-ima-devel@...ts.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-ima-devel


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists