Hello, I'm running a couple of FreeIPA servers as well as some Debian/Ubuntu/Fedora clients and keep poking at cockpit. I've read the documentation at for TLS at https://cockpit-project.org/guide/latest/https.html and SSO at https://cockpit-project.org/guide/latest/sso.html
For SSO with FreeIPA the principal is HTTP/[email protected]. In the keytab /etc/krb5.keytab we only have the principal host/[email protected]. On the FreeIPA server we have a principal HTTP/[email protected]. I also use HTTP/ for normal webservers (on non-FreeIPA servers) as well. The keytab for principal HTTP/ on FreeIPA servers is stored in /var/lib/ipa/gssproxy/http.keytab. That file is not accessibly from cockpit (I symlinked it and got an AVC denial). I could copy the file as /etc/cockpit/krb5.keytab and was able to log on with my kerberos ticket without password. Another possibility is to grant permission to retrieve the keytab to get a second copy - but that both needs redoing whenever I refresh the keytabs. What would be needed to use another principal like cockpit/[email protected] for the keytab? That way each service would use its own principal and keytab and avoid the retrieval and shared use. Do I miss something else and it's not that complex? For TLS the documentation says to generate the TLS certificate with getcert request -f ${CERT_FILE} -k ${KEY_FILE} -D $(hostname --fqdn) -C \ "sed -n w/etc/cockpit/ws-certs.d/50-from-certmonger.cert ${CERT_FILE} \ ${KEY_FILE}" [I did use ipa-getcert...] When I do that I get an AVC: type=AVC msg=audit(1633548839.586:8895): avc: denied { create } for pid=836449 comm="sed" name="50-from-certmonger.cert" scontext=system_u: system_r:certmonger_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0 According to https://adam.younglogic.com/2018/02/certmonger-selinux-keystores/ something like making the type of /etc/cockpit/ws-certs.d cert_t instead of etc_t works. After that cockpit didn't restart, because it could not read the certificate. "chgrp cockpit-ws /etc/cockpit/ws-certs.d/50-from-certmonger.cert" and "chmod g+r /etc/cockpit/ws-certs.d/50-from-certmonger.cert" finally made cockpit running again. Is that something that should be documented or better added to the cockpit packaging? I'll most likely drop the sed command and the permission fixup in a script in /usr/libexec/certmonger to fix it up. I've used "-K cockpit/$(hostname --fqdn)" as a parameter to ipa-getcert, so the certificate is attached to that service. That way I have no conflict with host certificates or a certificate attached to the HTTP/ principal. That way both the certificate and the keytab are attached to the same cockpit/ principal without interferring with HTTP/ services. Am I on the right track here or do I miss a simpler way? Jochen -- This space is intentionally left blank. _______________________________________________ cockpit-devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
