On 06/21/2017 02:23 AM, Jakub Hrozek wrote:
On Tue, Jun 20, 2017 at 04:23:30PM -0400, Daniel Walsh wrote:
On 06/20/2017 02:45 PM, Jakub Hrozek wrote:
On Tue, Jun 20, 2017 at 08:55:49AM -0400, Daniel Walsh wrote:
On 06/20/2017 04:21 AM, Jakub Hrozek wrote:
On Tue, Jun 20, 2017 at 09:25:49AM +0200, Pavel Cahyna wrote:
Hi,
On Tue, Jun 20, 2017 at 07:42:27AM +0200, Jan Kurik wrote:
= System Wide Change: Kerberos KCM credential cache by default =
https://fedoraproject.org/wiki/Changes/KerberosKCMCache
"The design is described in more detail on the SSSD wiki."
It is not, the link redirects to a page about fedorahosted.org
retirement.
Sorry, your are right, I fixed the link (this feature was submitted
during f-26 timeframe when fh.o was still up and I forgot to change the
links when I re-submitted the feature..)
The correct link is:
https://docs.pagure.org/SSSD.sssd/design_pages/kcm.html
Change owner(s):
* Jakub Hrozek <jhrozek AT redhat DOT com>
Default to a new Kerberos credential cache type called KCM which is
better suited for containerized environments and provides a better
user experience in the general case as well.
I wonder what is the relation to the daemon of the same name ansd
similar purpose distributed with Heimdal
http://h5l.org/manual/HEAD/info/heimdal/Credential-cache-server-_002d-KCM.html.
Will they be compatible?
Yes, more or less. The wire protocol is the same and I used MIT client
libraries with Heimdal server bit during development. Not all server
commands are implemented, only the subset that MIT client implements.
There are some features supported by Heimdal but not supported yet by SSSD's
KCM, like renewals, but those will be added. There are some features we
chose to explicitly not add (or not enable by default), like listing all
ccaches known to KCM server by root.
Hopefully the sssd upstream design page would help..
Will code be shared?
No, the Heimdal deamon relies on internal Heimdal API quite a bit. We
also want to support multiple 'storage back ends' for the ccaches, while
Heimdal only stores the ccaches in memory.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
How will I access this feature inside of a container?
Bind-mount the KCM server socket into the container.
If there is a leaked
socket into the container, what kind of access control is built into your
server to prevent root inside of one container effecting/accessing the
credentials of different containers?
Well, UID of the peer accessing the socket is the access control key right
now. Unlike Heimdal's KCM, root doesn't have any special powers (with
Heimdal's KCM, root can list any ccache, with our implementation, only
that of UID 0).
Do you have a different suggestion?
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
I would want an SELinux check added to it, to allow us to keep the caches
separate, based on SELinux. This would mean you would need to have an
SELinux label associated with each cache.
I would also be careful about capabilities.
The bottom line with this is if I have two different containers creating
keyrings, how does you cache differentiate the the keyrings from each other.
If I am in container1 and I do a kinit, and it container2, I can use the
keyring, that is a HUGE security violation.
Well, isn't the kernel KEYRING: cache (which we default to..) working
exactly this way at the moment?
With the KCM deamon, you at least selectively mount the KCM socket into
the containers where you /want/ to share the ccache based on the peer
UID.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
NO. The Kernel keyring inside of the container is blocked from
accessing other kernel keyrings by SELinux. But this causes issues,
because their is only one Kernel Keyring, so all containers are blocked
from using it after the first container. Currently kerberos inside of
containers will only work with fie or /dir where the files are mounted
into the container.
Well this would only be useful if you want more then one container to
use the same kerberos keyring.
We have talked in the past about ways of putting sssd sockets into
containers and having sssd define the separation through potentially
multiple sockets. Or making the protocol smart enough to look at the
cgroup of the calling process and giving it different data depending on
the cgroup.
From an SELinux point of view, you need to make sure this is not an
easy way to allow communications or attack vectors between confined
domains. Just something you should think about. You are dealing with
security sensitive data and if we have to allow confined domains to
communicate with this socket, it can lead to problems.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
