From 8cdac3a9c1dab4e3b8c8afc68f51baa45d1ce6d4 Mon Sep 17 00:00:00 2001
From: Luke Hinds <lhinds@redhat.com>
Date: Thu, 20 Oct 2022 06:05:48 +0100
Subject: [PATCH 1/5] Add ignore path option

Signed-off-by: Luke Hinds <lhinds@redhat.com>
---
 91-ignore-path-for-ima.md | 259 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 259 insertions(+)
 create mode 100644 91-ignore-path-for-ima.md

diff --git a/91-ignore-path-for-ima.md b/91-ignore-path-for-ima.md
new file mode 100644
index 0000000..2f38e28
--- /dev/null
+++ b/91-ignore-path-for-ima.md
@@ -0,0 +1,259 @@
+<!--
+**Note:** When your enhancement is complete, all of these comment blocks should be removed.
+
+To get started with this template:
+
+- [ ] **Create an issue in keylime/enhancements**
+  When filing an enhancement tracking issue, please ensure to complete all
+  fields in that template.  One of the fields asks for a link to the enhancement.  You
+  can leave that blank until this enhancement is made a pull request, and then
+  go back to the enhancement and add the link.
+- [ ] **Make a copy of this template.**
+ name it `NNNN-short-descriptive-title`, where `NNNN` is the issue number (with no
+  leading-zero padding) assigned to your enhancement above.
+- [ ] **Fill out this file as best you can.**
+  At minimum, you should fill in the "Summary", and "Motivation" sections.
+  These should be easy if you've preflighted the idea of the enhancement with the
+  appropriate SIG(s).
+- [ ] **Merge early and iterate.**
+  Avoid getting hung up on specific details and instead aim to get the goals of
+  the enhancement clarified and merged quickly.  The best way to do this is to just
+  start with the high-level sections and fill out details incrementally in
+  subsequent PRs.
+-->
+# enhancement-NNNN: Your short, descriptive title
+
+<!--
+This is the title of your enhancement.  Keep it short, simple, and descriptive.  A good
+title can help communicate what the enhancement is and should be considered as part of
+any review.
+-->
+
+<!--
+A table of contents is helpful for quickly jumping to sections of a enhancement and for
+highlighting any additional information provided beyond the standard enhancement
+template.
+-->
+
+<!-- toc -->
+- [Release Signoff Checklist](#release-signoff-checklist)
+- [Summary](#summary)
+- [Motivation](#motivation)
+  - [Goals](#goals)
+  - [Non-Goals](#non-goals)
+- [Proposal](#proposal)
+  - [User Stories (optional)](#user-stories-optional)
+    - [Story 1](#story-1)
+    - [Story 2](#story-2)
+  - [Notes/Constraints/Caveats (optional)](#notesconstraintscaveats-optional)
+  - [Risks and Mitigations](#risks-and-mitigations)
+- [Design Details](#design-details)
+  - [Test Plan](#test-plan)
+  - [Upgrade / Downgrade Strategy](#upgrade--downgrade-strategy)
+- [Drawbacks](#drawbacks)
+- [Alternatives](#alternatives)
+- [Infrastructure Needed (optional)](#infrastructure-needed-optional)
+<!-- /toc -->
+
+## Release Signoff Checklist
+
+<!--
+**ACTION REQUIRED:** In order to merge code into a release, there must be an
+issue in [keylime/enhancements] referencing this enhancement and targeting a release**.
+
+For enhancements that make changes to code or processes/procedures in core
+Keylime i.e., [keylime/keylime], we require the following Release
+Signoff checklist to be completed.
+
+Check these off as they are completed for the Release Team to track. These
+checklist items _must_ be updated for the enhancement to be released.
+-->
+
+- [ ] Enhancement issue in release milestone, which links to pull request in [keylime/enhancements]
+- [ ] Core members have approved the issue with the label `in-progress`
+- [ ] Design details are appropriately documented
+- [ ] Test plan is in place
+- [ ] User-facing documentation has been created in [keylime/keylime-docs]
+
+<!--
+**Note:** This checklist is iterative and should be reviewed and updated every time this enhancement is being considered for a milestone.
+-->
+
+## Summary
+
+<!--
+This section is incredibly important for producing high quality user-focused
+documentation such as release notes or a development roadmap.  It should be
+possible to collect this information before implementation begins in order to
+avoid requiring implementers to split their attention between writing release
+notes and implementing the feature itself. Reviewers
+should help to ensure that the tone and content of the `Summary` section is
+useful for a wide audience.
+
+A good summary is probably at least a paragraph in length.
+-->
+
+It may not always be evident to a user on what the final location of a file may
+be. This enhancement proposes a new config value that allows a user to have IMA
+measurements ignore the location of a file and only work with the filename
+itself.
+
+## Motivation
+
+<!--
+This section is for explicitly listing the motivation, goals and non-goals of
+this enhancement.  Describe why the change is important and the benefits to users.
+-->
+
+Some systems may have files that are in different locations depending on the
+system. For example, a file may be in `/usr/bin` on one system and `/bin` on
+another. This can cause issues with IMA measurements as the location of the file
+is included in the measurement. This enhancement proposes a new config value
+that allows a user to have IMA measurements ignore the location of a file and
+only work with the filename itself.
+
+### Goals
+
+<!--
+List the specific goals of the enhancement.  What is it trying to achieve?  How will we
+know that this has succeeded?
+-->
+
+Allow users to only state a filename to be measured and not the full path.
+
+### Non-Goals
+
+<!--
+What is out of scope for this enhancement?  Listing non-goals helps to focus discussion
+and make progress.
+-->
+
+## Proposal
+
+<!--
+This is where we get down to the specifics of what the proposal actually is.
+This should have enough detail that reviewers can understand exactly what
+you're proposing, but should not include things like API designs or
+implementation.  The "Design Details" section below is for the real
+nitty-gritty.
+-->
+
+A value `ignore-path` is introduced to the `keylime.conf` file. When this value
+is set to `True`, the location of a file is ignored when performing IMA
+measurements on the verifier.
+
+### User Stories (optional)
+
+<!--
+Detail the things that people will be able to do if this enhancement is implemented.
+Include as much detail as possible so that people can understand the "how" of
+the system.  The goal here is to make this feel real for users without getting
+bogged down.
+-->
+
+I have a system that has a file that is in different locations depending on the
+deployment. I want to measure this file but I don't want to have to specify the
+full path to the file, as the value is arbitrary.
+
+#### Story 1
+
+#### Story 2
+
+### Notes/Constraints/Caveats (optional)
+
+<!--
+What are the caveats to the proposal?
+What are some important details that didn't come across above.
+Go in to as much detail as necessary here.
+This might be a good place to talk about core concepts and how they relate.
+-->
+
+### Risks and Mitigations
+
+<!--
+What are the risks of this proposal and how do we mitigate.  Think broadly.
+For example, consider both security and how this will impact the larger
+enhancement ecosystem.
+
+How will security be reviewed and by whom?
+-->
+
+## Design Details
+
+<!--
+This section should contain enough information that the specifics of your
+change are understandable.  This may include API specs (though not always
+required) or even code snippets.  If there's any ambiguity about HOW your
+proposal will be implemented, this is the place to discuss them.
+-->
+
+The `ignore-path` value is added to the `keylime.conf` file. When this value is
+set to `True`, the location of a file is ignored
+
+This will be set as False by default, meaning it is an opt-in feature.
+
+### Test Plan
+
+<!--
+**Note:** *Not required until targeted at a release.*
+
+Consider the following in developing a test plan for this enhancement:
+- Will there be e2e and integration tests, in addition to unit tests?
+- How will it be tested in isolation vs with other components?
+
+No need to outline all of the test cases, just the general strategy.  Anything
+that would count as tricky in the implementation and anything particularly
+challenging to test should be called out.
+
+All code is expected to have adequate tests (eventually with coverage
+expectations).
+-->
+
+### Upgrade / Downgrade Strategy
+
+<!--
+If applicable, how will the component be upgraded and downgraded? Make sure
+this is in the test plan.
+
+Consider the following in developing an upgrade/downgrade strategy for this enhancement
+-->
+
+### Dependencie requirements
+
+<!--
+If your new change requires new dependencies, please outline and demonstrate that your selected dependency 
+is well maintained and packaged in Keylime's supported Operating Systems (currently Debian Stable
+and as of time writing Fedora 32/33). 
+
+During code implementation you will also be expected to add the package to CI , the keylime ansible role and 
+keylimes main installer (`keylime/installers.sh`).
+
+If the package is not available in the supported Operated systems, the PR will not be merged into master. 
+
+Adding the package in `requirements.txt` is not sufficent for master which is where we tag releases from. 
+
+You may however be able to work within an experimental branch until a package is made available. If this is
+the case, please outline it in this enhancement.
+
+-->
+
+## Drawbacks
+
+<!--
+Why should this enhancement _not_ be implemented?
+-->
+
+## Alternatives
+
+<!--
+What other approaches did you consider and why did you rule them out?  These do
+not need to be as detailed as the proposal, but should include enough
+information to express the idea and why it was not acceptable.
+-->
+
+## Infrastructure Needed (optional)
+
+<!--
+Use this section if you need things infrastructure related specific to your enhancement.  Examples include a
+new subproject, repos requested, github webhook, changes to CI (travis).
+-->

From e55675e05ab11ea9a2313389ea797fdf9aadd7b1 Mon Sep 17 00:00:00 2001
From: Luke Hinds <lhinds@redhat.com>
Date: Thu, 20 Oct 2022 06:16:07 +0100
Subject: [PATCH 2/5] Change to optional-paths

Signed-off-by: Luke Hinds <lhinds@redhat.com>
---
 91-ignore-path-for-ima.md | 35 +++++++++++++++++++++--------------
 1 file changed, 21 insertions(+), 14 deletions(-)

diff --git a/91-ignore-path-for-ima.md b/91-ignore-path-for-ima.md
index 2f38e28..666183e 100644
--- a/91-ignore-path-for-ima.md
+++ b/91-ignore-path-for-ima.md
@@ -95,7 +95,7 @@ A good summary is probably at least a paragraph in length.
 
 It may not always be evident to a user on what the final location of a file may
 be. This enhancement proposes a new config value that allows a user to have IMA
-measurements ignore the location of a file and only work with the filename
+measurements with a full path and only work with the filename
 itself.
 
 ## Motivation
@@ -106,11 +106,15 @@ this enhancement.  Describe why the change is important and the benefits to user
 -->
 
 Some systems may have files that are in different locations depending on the
-system. For example, a file may be in `/usr/bin` on one system and `/bin` on
-another. This can cause issues with IMA measurements as the location of the file
-is included in the measurement. This enhancement proposes a new config value
-that allows a user to have IMA measurements ignore the location of a file and
-only work with the filename itself.
+deployment. For example, a file may be in `/opt/my_app` on one system and
+`/usr/my_app` on another. This can cause issues with IMA measurements as the
+location of the file is included in the allowlist. This enhancement proposes
+a new config value that allows a user to have keylime IMA ignore the path of a 
+file and only work with the filename itself.
+
+This will especially be useful for users who want an application monitored by
+keylime to be able to be deployed in different locations, more than an entire
+OS.
 
 ### Goals
 
@@ -138,9 +142,10 @@ implementation.  The "Design Details" section below is for the real
 nitty-gritty.
 -->
 
-A value `ignore-path` is introduced to the `keylime.conf` file. When this value
-is set to `True`, the location of a file is ignored when performing IMA
-measurements on the verifier.
+A value `optional-paths` is introduced to the `keylime.conf` file. When this value
+is set to `True`, if a file is without a leading POSIX path separator then the
+file is still measured. If the file has a leading POSIX path separator then the
+file is measured still, as per the current behaviour.
 
 ### User Stories (optional)
 
@@ -151,9 +156,9 @@ the system.  The goal here is to make this feel real for users without getting
 bogged down.
 -->
 
-I have a system that has a file that is in different locations depending on the
-deployment. I want to measure this file but I don't want to have to specify the
-full path to the file, as the value is arbitrary.
+I have a system that has a file that may be situated in an arbitary location
+depending on the deployment. I want to measure this file but I don't want to
+have to specify the full path to the file.
 
 #### Story 1
 
@@ -187,8 +192,10 @@ required) or even code snippets.  If there's any ambiguity about HOW your
 proposal will be implemented, this is the place to discuss them.
 -->
 
-The `ignore-path` value is added to the `keylime.conf` file. When this value is
-set to `True`, the location of a file is ignored
+The `optional-paths` value is added to the `keylime.conf` file. When this value is
+set to `True`, the location of a file is ignored if no proceeding POSIX path is
+specified. If a proceeding POSIX path is specified, the file is measured as per
+the current behaviour.
 
 This will be set as False by default, meaning it is an opt-in feature.
 

From b4d9fb0f260cf007090ee287ea20587348148082 Mon Sep 17 00:00:00 2001
From: Luke Hinds <lhinds@redhat.com>
Date: Thu, 20 Oct 2022 06:26:08 +0100
Subject: [PATCH 3/5] Improve wording

Signed-off-by: Luke Hinds <lhinds@redhat.com>
---
 91-ignore-path-for-ima.md | 36 +++++++++++++++++++++---------------
 1 file changed, 21 insertions(+), 15 deletions(-)

diff --git a/91-ignore-path-for-ima.md b/91-ignore-path-for-ima.md
index 666183e..548a32b 100644
--- a/91-ignore-path-for-ima.md
+++ b/91-ignore-path-for-ima.md
@@ -94,9 +94,9 @@ A good summary is probably at least a paragraph in length.
 -->
 
 It may not always be evident to a user on what the final location of a file may
-be. This enhancement proposes a new config value that allows a user to have IMA
-measurements with a full path and only work with the filename
-itself.
+be when creating an allowlist. This enhancement proposes a new config value
+that allows a user to work with both filenames with an arbitrary path, alongside
+the current behavior of a full path set.
 
 ## Motivation
 
@@ -106,15 +106,19 @@ this enhancement.  Describe why the change is important and the benefits to user
 -->
 
 Some systems may have files that are in different locations depending on the
-deployment. For example, a file may be in `/opt/my_app` on one system and
-`/usr/my_app` on another. This can cause issues with IMA measurements as the
-location of the file is included in the allowlist. This enhancement proposes
-a new config value that allows a user to have keylime IMA ignore the path of a 
-file and only work with the filename itself.
+deployment. For example, a file `widgets` may be in `/opt/my_app` on one system 
+and `/usr/my_app` on another. This enhancement proposes a new config value that
+allows a user to have keylime IMA ignore the path of a file if not present.
 
 This will especially be useful for users who want an application monitored by
-keylime to be able to be deployed in different locations, more than an entire
-OS.
+keylime that may deploy to different systems with different paths.
+
+It would then allow an upstream project to generate signed allowlists that can
+be used by downstream systems without having to modify the allowlist to set
+deployment specific paths.
+
+However, those wanting the stronger guarantees of a full path set will still be
+able to leverage that behavior.
 
 ### Goals
 
@@ -123,7 +127,8 @@ List the specific goals of the enhancement.  What is it trying to achieve?  How
 know that this has succeeded?
 -->
 
-Allow users to only state a filename to be measured and not the full path.
+Allow users to only state a filename to be measured and not always the full
+path.
 
 ### Non-Goals
 
@@ -142,10 +147,11 @@ implementation.  The "Design Details" section below is for the real
 nitty-gritty.
 -->
 
-A value `optional-paths` is introduced to the `keylime.conf` file. When this value
-is set to `True`, if a file is without a leading POSIX path separator then the
-file is still measured. If the file has a leading POSIX path separator then the
-file is measured still, as per the current behaviour.
+A bool config value `optional-paths` is introduced to the `keylime.conf` file.
+When this value is set to `True`, if a file is without a leading POSIX path
+then the file is still measured. If the file has a leading POSIX path separator
+then the file is measured, as per the current behaviour, where the full path
+dictates the comparision of the allowlist value to that recorded by IMA.
 
 ### User Stories (optional)
 

From 0e57c98ba7d6c1f632713c71394b8df13dadae33 Mon Sep 17 00:00:00 2001
From: Luke Hinds <lhinds@redhat.com>
Date: Thu, 20 Oct 2022 06:31:38 +0100
Subject: [PATCH 4/5] Add case for duplicates

Signed-off-by: Luke Hinds <lhinds@redhat.com>
---
 91-ignore-path-for-ima.md | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/91-ignore-path-for-ima.md b/91-ignore-path-for-ima.md
index 548a32b..e255b06 100644
--- a/91-ignore-path-for-ima.md
+++ b/91-ignore-path-for-ima.md
@@ -205,6 +205,14 @@ the current behaviour.
 
 This will be set as False by default, meaning it is an opt-in feature.
 
+If a file is specified without a file path, alongside a duplicate filename with
+a path, the file with the file path will be measured and the file without the
+file path will be ignored.
+
+e.g. 
+
+`as983o... widget` will be ignored if `as983o... /opt/my_app/widget` is present.
+
 ### Test Plan
 
 <!--

From b07d57d9ab828f4c6ca66875107d0facc1b0fce4 Mon Sep 17 00:00:00 2001
From: Luke Hinds <lhinds@redhat.com>
Date: Thu, 20 Oct 2022 06:32:58 +0100
Subject: [PATCH 5/5] Add GH issue number

Signed-off-by: Luke Hinds <lhinds@redhat.com>
---
 91-ignore-path-for-ima.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/91-ignore-path-for-ima.md b/91-ignore-path-for-ima.md
index e255b06..00bec46 100644
--- a/91-ignore-path-for-ima.md
+++ b/91-ignore-path-for-ima.md
@@ -21,7 +21,7 @@ To get started with this template:
   start with the high-level sections and fill out details incrementally in
   subsequent PRs.
 -->
-# enhancement-NNNN: Your short, descriptive title
+# enhancement-91: Optional Path for IMA measurement
 
 <!--
 This is the title of your enhancement.  Keep it short, simple, and descriptive.  A good