This work depends on SELinux policy patches, moving to 1.16.1

Here are some uses cases based on the upstream design page, sprinkled with
cases where we might protect against accidentally allowing access:

0) How is KEYRING confined at the moment? What happens if one identity
creates some secrets in keyring, what are the rules preventing or allowing
another identity from accessing the secrets?

1) KCM running in one container, we want the ccaches to be reachable by container kcmclient, but not container otherclient

Consider that the KCM server is listening on /kcmserver

podman run -t -i --name=kcmserver -h=kcmserver -v=/kcmserver fedora /bin/bash
podman run -t -i --name=kcmclient -h=kcmclient --volumes-from=kcmserver fedora /bin/bash
podman run -t -i --name=otherclient -h=otherclient fedora /bin/bash

Here we are trying to protect the socket leaking (as a result of a
misconfiguration or a bug) into otherclient. The leak could be simulated by running the client as:

podman run -t -i --name=otherclient -h=otherclient --volumes-from=kcmserver fedora /bin/bash

Perhaps this could already be achieved by launching the containers with
explicit --security-opt label=level:s0:cXYZ,cABC and using the -Z
option for the client container?

2) KCM running on the host, we want to prevent a container accessing the
socket by accidental mounting of /var/run or other location where the KCM
socket is created.

In this case, whatever is created in the container is created as the UID
of whoever ran the libkrb5 operation. If the container is running with
the same UID as the identity that created If we had the ACLs consider the
(user,role,type,label) of the caller, we could have used that for access
control, too.

3) KCM running on the host, we want to ALLOW a container to access
certain credentials from the host. (And we assume the ACLs take the labels
etc in account)

Could we just have the user set the label same as the creator of the
cache with --security-opt?

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4461

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.