IPC API for use with containers

[DemiMarie]

Due to (notably) differences in libc, it’s rarely possible for a library built for the host to run in a container reliably. It would be very nice to have an IPC API that containers could use so that they could use host-provided certificates and revocation information.

[djc]

What is the concrete problem you've run into?

[DemiMarie]

I haven’t run into it myself, but I do know that running a host-provided shared library from the host in the container is not expected to work. That’s why XDG portals all use IPC APIs rather than library APIs.

I’d also like to centralize things like extra trusted certificates and explicitly distrusted certificates.

That said, this issue was made under the (mistaken?) assumption that upki involves a persistent daemon. If it doesn’t, then mounting the data read-only into the container is sufficient.

[djc]

Yes. For now there are no daemons involved (although the container would depend on the host to keep revocation data up to date).

[DemiMarie]

Is that revocation data signed in any way? I’m working on a system (Spectrum, https://spectrum-os.org) where the host has no network access. Is it possible for it to task a VM with fetching the data and then verify its integrity?

[ctz]

Inheriting the arrangement of "upstream" crlite, the filter data is obtained over authenticated HTTPS but otherwise is assumed to be trusted by the user doing the revocation query (maybe they fetched it themselves, or rely on data fetched at a system level). If a more detailed trust model is required, that could theoretically be layered upon upki (eg, one actor fetches and countersigns, another verifies the countersignature prior to use) but that would be outside the scope of this project.

The effects of using maliciously-provided revocation data should be limited to a full set of revocation outcomes (ranging from no certificates are revoked, to all certificates are revoked). As a revocation-checking system, there is no route for certificates to become newly trusted, or expired certificates to be unexpired -- both of those are out of scope of upki and part of path building. Items that require that level of assurance (such as, but not limited to, distribution of root certificates) are out of scope for the upki project precisely for that reason.