55_revocation_actions_without_python.md

enhancement-55: Revocation Actions without Python Runtime

• Release Signoff Checklist
• Summary
• Motivation
  • Goals
  • Non-Goals
• Proposal
  • User Stories (optional)
    • Story 1
    • Story 2
  • Notes/Constraints/Caveats (optional)
  • Risks and Mitigations
• Design Details
  • Test Plan
  • Upgrade / Downgrade Strategy
• Drawbacks
• Alternatives
• Infrastructure Needed (optional)

Release Signoff Checklist

• Enhancement issue in release milestone, which links to pull request in [keylime/enhancements]
• Core members have approved the issue with the label implementable
• Design details are appropriately documented
• Test plan is in place
• User-facing documentation has been created in [keylime/keylime-docs]

Summary

This enhancement proposal allows revocation actions to be any executable or script, not only a Python module.

Motivation

Currently Keylime requires that agent-local actions executed at revocation notification to be written in Python with a specific convention: an async execute function is globally defined and it takes a revocation message as the argument.

With the upcoming addtion of the new Rust-based keylime agent there will need to be a means to execute actions without Python runtime installation.

Goals

• Arbitrary scripts/executable can be used as a revocation action

Non-Goals

• Secure execution of revocation actions (while it is desired), such as using sandbox and seccomp

Proposal

The actions defined in the configuration file (or tenant-provided action list) can be any type of script/executable. The actions names are no longer required to begin with local_action_.

When Keylime agent receives a revocation message, it stores the JSON payload in a file and invokes revocation actions with the file as a command-line argument.

User Stories (optional)

Story 1

• The agent is configured with revocation notification enabled
• The agent is also configured with non-Python actions (pre-installed on the system) set up in the revocations_actions configuration option
• The verifier notifies a revocation
• The agent will invoke the actions with the revocation message stored in a file
• If any Python actions are installed alongside non-Python actions, the agent will search and invoke them in the same convention as used before, after non-Python actions are invoked

Story 2

• The agent is configured with revocation notification enabled
• The tenant sends non-Python actions as part of the initial payload, as well as the action_list file listing those actions
• The verifier notifies a revocation
• The agent will invoke the actions with the revocation message stored in a file
• If any Python actions are installed alongside non-Python actions, the agent will search and invoke them in the same convention as used before, after non-Python actions are invoked

Notes/Constraints/Caveats (optional)

Risks and Mitigations

This mechanism makes it a little easier for the attacker to execute commands on the system, though the same thing is already possible by injecting custom Python actions. To keep the risk minimal, this proposal suggest mandating that the pre-installed actions are installed in a fixed/immutable directory, such as /usr on modern Linux distributions rather than /var/lib or similar. That way the action commands will also be subject to attestation.

Design Details

The actions defined with the revocations_actions configuration option (or in the unzipped/action_list file provided by the tenant) can be of the command names of scripts/executables. The names are no longer required to begin with local_action_.

There are two possibilities where the actual action can be found: pre-installed on the system or sent by the tenant as part of the initial encrypted payload (secure payload).

The following couple of new options are added to the [cloud_agent] section of the configuration file:

• revocation_actions_dir (string): The location where pre-installed actions are found. It is suggested that this points to a fixed/immutable location subject to attestation. The default is /usr/libexec/keylime. See Risks and Mitigations for details.
• allow_payload_revocation_actions (boolean): Whether to invoke revocation actions sent as part of payload. The default is True and turning it off allows the agent to limit actions to only pre-installed ones for more security.

For backward compatibility, if there is no corresponding script/executable found on the system nor in the secure payload, the agent may fall back to the Python-based actions.

The actual lookup procedure of the actions is as follows:

1. Look for the named command on the system
2. Look for the named command in the tenant-provided initial payload
3. If the agent supports Python actions, look for the Python module on the system
4. If the agent supports Python actions, look for the Python module in the tenant-provided initial payload

The command takes a command-line argument: the absolute path to the file where the revocation message is stored in JSON. Before being invoked, the process' working directory will be changed to the secure mount directory (/var/lib/keylime/secure) where any initial payload is extracted and stored.

Test Plan

• A new unit test should be added to exercise action lookup
• A new integration test should be written to exercise revocation actions

Upgrade / Downgrade Strategy

When downgrading, non-Python actions will stop working. Proper log messages would help diagnose the issues.

Dependencie requirements

No dependencies are known of.

Drawbacks

No drawbacks are known of.

Alternatives

• It would also be an option to make use of an embeddable language runtime, such as Lua and mruby.

Infrastructure Needed (optional)

No infrastructure change needed.