Build In Providers are not accessible from the external plugins

[mnltejaswini]

The store "oras" is made a built in plugin in the framework. This model breaks the access of this store to the external plugins like sbom verifier. Current code base for sbom verifier is not functional and has to be fixed

[etrexel]

Looking at go plugins it seems like we could have plugins built with exported functions for referrer store and verifier interfaces that could be called directly from the executor. This would allow us to pass references to referrer stores and/or verifiers that have already been generated by the executor. The docs indicate that this is only supported on Linux and MacOS, so we would lose Windows support with this approach.

Hashicorp also has a library utilizing a sub-process and communication via gRPC called go-plugin. They use this for projects such as Vault and prefer this over the built-in plugin support for security reasons. I think this would also allow us to maintain support of all major operating systems.

[etrexel]

Looked at go-plugin a little more over the weekend. They have an example of bi-directional communication between the executor and the plugin via gRPC. We could have the executor configure both the verifier and store plugins and then pass the store plugin gRPC client to the verifier.

[sajayantony]

/cc @shizhMSFT the hashicorp model seems like an option to consider for notation extensibility.

[shizhMSFT]

Since we are building a security product, we also need to consider computer security on the plugin system, especially paying attention to the ACL.

If we use the hashicorp model / gRPC, we need to use mTLS on the communication channel between the host and the plugin since it is possible that the plugin is running as another user and has different permissions. Besides, the user experience might not be good if the user has to configure lots of keys and certs for TLS.

[sajayantony]

Can we restrict the plugins to create domain sockets with limited scoped permissions so that the ACLs are bound to the the user process only?

[shizhMSFT]

Unix sockets with ACL might work. Note: Unix sockets work on Windows 10 or later with go 1.12 or later.

However, permissions are not always honored in UNIX for unix sockets. As in man unix (page 7),

On Linux, connecting to a stream socket object requires write permission on that socket; sending a datagram to a datagram socket likewise requires write permission on that socket. POSIX does not make any statement about the effect of the permissions on a socket file, and on some systems (e.g., older BSDs), the socket permissions are ignored. Portable programs should not rely on this feature for security.

Windows has the same level of the security as Linux (see doc).