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/server.example.com(a)EXAMPLE.COM. In the keytab /etc/krb5.keytab we
only have the principal host/server.example.com(a)EXAMPLE.COM. On the
FreeIPA server we have a principal HTTP/server.example.com(a)EXAMPLE.COM.
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/server.example.com(a)EXAMPLE.COM 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