Feature Request: Enhance the "unix" workload attestor to allow discovery of symbols

Description

We propose adding an experimental feature to the unix workload attestor to check for specific symbols in binaries. This feature would enable attestation based on the presence of certain symbols.

Proposed Configuration

WorkloadAttestor "unix" {
    plugin_data {
        experimental {
            discover_symbols = ["v2._cfunc_go_openssl", "openssl.strictfips", "fipstls.required"]
        }
    }
}

discover_symbols is a list of symbols that the attestor will look for in the binary.

Use Case

In scenarios where binaries are compiled using specific libraries, certain symbols are expected to be present within the binaries. This feature can verify if a workload is running a binary built with these specific libraries by checking for the presence of these symbols in the binaries. This ensures that the binaries meet the required build criteria, such as using FIPS-compliant libraries.

Selectors

The new selectors would be generated based on the discovery of specified symbols. For example:

unix:symbol:openssl.strictfips
unix:symbol:fipstls.required

Additionally, a general selector indicating that symbols were found could be included:

unix:symbols:found

Technical Considerations and Limitations

Dependency on Symbol Table

This functionality relies on the binary containing a symbol table. If the symbol table is missing, the Symbols() function will return an error. This is a crucial failure mode to consider.

Limitations

It is important to note that this is not a very strong attestation mechanism on its own, as the binary could be compiled with a library that spoofed the function names. Therefore, it needs to be combined with other mechanisms to ensure the compilation was not tampered with.

Rationale for Experimental Status

This feature is proposed as experimental because its utility and requirements may vary across different use cases. Introducing it experimentally allows us to validate that the configuration options and the shape of the selectors adapt well to all use cases and make necessary adjustments based on feedback.

Failure Modes

Missing Symbol Table: If the binary lacks a symbol table, the attestation will fail. The implementation should potentially handle this scenario gracefully by logging a clear error message and skipping the symbol check.

Additional Considerations

Enablement Dependency: Should it be enabled only when DiscoverWorkloadPath is set to true or should it be independent from that configuration option? The symbols discovery needs the additional permissions required when using DiscoverWorkloadPath.
Case Sensitivity: Should the symbols be treated and compared always in lowercase for user convenience to avoid misspellings? Symbols typically contain a mix of uppercase and lowercase letters along with other characters, and normalizing them to lowercase could reduce errors and improve usability.

Performance Measurements

We conducted preliminary performance measurements to assess the impact of adding the symbol discovery feature to the Unix workload attestor. Below are the results comparing the regular attestation process, attestation with symbol discovery, and attestation with SHA256 calculation.

Sample	Unix Workload Attestation (Regular)	Unix Workload Attestation (With Symbol Discovery)	Unix Workload Attestation (With SHA256 Calculation)
1	296.445µs	9.953879ms	62.644081ms
2	325.788µs	11.425229ms	65.261771ms
3	308.155µs	8.06851ms	64.118936ms
4	279.115µs	8.58554ms	63.407016ms
Average	302.376µs	9.50879ms	63.857451ms

Analysis

Adding the symbol discovery feature significantly increases the attestation time, bringing it to an average of around 9-11ms. While this is a noticeable increase, it is still within an acceptable range for many use cases and it is much faster than the SHA256 calculation.

Version:
Platform:
Subsystem:

spiffe / spire