Ratsd Plugins

[cowbon]

Neither Golang modules or Rust Crates supports signature at this moment. There's an RFC in Rust trying to bring in signature verification but it's still yet to be merged. Does it make sense to make plugins as packages, such as .yum or .dpkg, and use GPG to verify signatures to ensure trustworthiness?

[deeglaze]

The trustworthiness would be dependent on the packager of /usr/ not the loader of the module. Are you designing for the attesters to be on a mutable volume?

[cowbon]

The trustworthiness would be dependent on the packager of /usr/ not the loader of the module. Are you designing for the attesters to be on a mutable volume?

I'm thinking of them as user space programs. I'm not sure if there's a good immutable volume we can take advantage of.

[deeglaze]

dm-verity read-only protected /usr/ is becoming the norm for OSes with strong attestation. https://0pointer.net/blog/fitting-everything-together.html

[cowbon]

I believe ratsd should be decoupled with OSes, and the goal is still to verify the signature of each attester.

[thomas-fossati]

A viable option in the Go ecosystem is https://github.com/hashicorp/go-plugin. They are separate processes that communicate over gRPC. Therefore, they can be written in any language. Their architecture is not particularly efficient throughput-wise. But they are robust and have nice isolation properties. I am not sure if they allow signature verification at load time, we'd need to check.

[cowbon]

Go-plugin does provide a way to verify the checksum of the plugin matches the expected value in SecureConfig, it still doesn't provide a way to validate the signature of the modules. What's possible to achieve is to extend the verification to support signatures in go-plugin.

[thomas-fossati]

Thanks for digging up the information!

From go-plugin#SecureConfig's docs:

The host process should ensure the checksum was provided by a trusted and authoritative source.

and then

The binary should be installed in such a way that it can not be modified by an unauthorized user between the time of this check and the time of execution.

[cowbon]

Hi @thomas-fossati , yes, go-plugin implements the checksum check. But this is very similar to go.sum, there's no way to specify a signature. I'd wonder what'd be the next step, should we first not worry about the signature and go with the checksum from go-plugin, let alone the performance degradation, or modify go-plugin to accept signatures?

[thomas-fossati]

Hi @thomas-fossati , yes, go-plugin implements the checksum check. But this is very similar to go.sum, there's no way to specify a signature. I'd wonder what'd be the next step, should we first not worry about the signature and go with the checksum from go-plugin, let alone the performance degradation, or modify go-plugin to accept signatures?

ISTM that:

• strong provenance checks for the go-plugin, and
• installation in a "safe" location

can be framed as strong requirements for the system/distro manager.

[cowbon]

Go-plugin mentions Plugins are very easy to install: just put the binary in a location where the host will find it (depends on the host but this library also provides helpers), and the plugin host handles the rest. Can we start with some leaf attesters as go-plugins and defer the packaging later? I guess /usr` may be a good candidate for a "safe" location, and how to install the attester is managed by the system/distro manager, thus beyond the scope of ratsd.