Hello Jochen, Jochen Kellner [2021-10-07 21:15 +0200]: > 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].
So I take it that principal already existed before cockpit, it's not the one that cockpit itself created during joining the domain? (As described on https://cockpit-project.org/guide/latest/sso.html#sso-server) > 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. Right, neither is ideal. We don't want to run cockpit' webserver as root, but as a very unprivileged system user -- this is good for restricting the impact of security issues, but of course makes this kind of strong demands on file system permissions. I'm afraid right now there is no better way of doing this than actually copying the file and adjusting its permissions/SELinux type. Possibly you can add that to your configuration management somehow? For the TLS certificate, we recently had the idea that cockpit.service could have a pre-start command that copies the certificate into /run/cockpit/ and adjusts the permissions as necessary. That would make it a lot simpler (and even possible) to share a certificate between multiple services, as otherwise one can never put correct permissions on the secret keys. The same scheme would actually work for the cockpit keytab. This is in our quarterly plan now (https://issues.redhat.com/browse/COCKPIT-814 but sorry, that's internal). > 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. I'm afraid I'm no kerberos expert, so this is just guessing: I thought that the HTTP/ service was dictated by what browsers actually accept as a principal for authenticating to remote web servers? Other than that, pretty much the only place that hardcodes it is /usr/libexec/cockpit-certificate-helper (in Debian/Ubuntu it is in /usr/lib/cockpit/), which is just a shell script, at least in recent Cockpit versions. That script more or less does the same ipa-getkeytab etc. commands as in sso.html. The actual authentication (cockpit-session) just expects it in /etc/cockpit/krb5.keytab, so if the browser is happy with a cockpit/ service prefix, then so much the better. > 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? Eek, thanks for reporting! I filed https://github.com/cockpit-project/cockpit/issues/16450 about this, and added it to our current quarterly plan, this is quite important. The above schema for copying the cert to /run ought to take care of the reading permission issues, but of course certmonger needs to be able to write the cert in the first place. > 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. And that works fine with browsers? If so, nice! Happy to adjust the documentation that any other prefix works as well. Martin _______________________________________________ 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
