Optional Paths Proposal

[lukehinds]

Signed-off-by: Luke Hinds [email protected]

[mbestavros]

I think this is a great idea! This will especially be helpful for upstream (pre-Keylime) policy generation, because it's possible that whatever tool creates a Keylime policy will have no information about where individual files will end up on a client system. Allowing a blanket hash match in that case, regardless of the path, would make that kind of policy generation way more viable.

I've got a few notes on the proposal as it stands:

• This makes reference to an optional-paths config value in keylime.conf; however, Keylime recently implemented split config files, so a global config value like that won't work. We may have to spread that value across several different components (e.g. tenant.conf and verifier.conf. Then again, if all allowlist processing happens on the verifier, then it may only be needed there.

• It's worth thinking about how path-less rules may interact with other rules in an allowlist. For example, let's assume we're monitoring a system with an allowlist that has an entry for the widget binary in two places: one with a file path (let's say var/lib/widget), and one without. How does Keylime behave in corner cases?

For example, let's say the client system has the widget binary (same hash and everything), but in /usr/lib/keylime instead. Under normal Keylime rules, this would fail (since the path is wrong), but now we have a pathless rule that says it should pass. Which one is right? Which one should take precedence? Should pathless rules override pathed rules?

It seems to me like the safest option would be the conservative one: if a file hash triggers multiple allowlist entries, any entries with a path should be prioritized over a blanket, pathless rule.