Hallo Martin,
thanks for your answer and your work on cockpit.
Martin Pitt <mpitt(a)redhat.com> writes:
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)
I normally joined the systems with ipa-client-install. When I next
install a new server I'll use cockpit to join and check how that looks.
My current push to look into cockpit somewhat deeper was my FreeIPA on
Fedora, which suggested enabling cockpit. and FreeIPA uses HTTP/
principal already.
> 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?
I'm using Ansible (started manually when needed). For my environment I
can probably live with it. But I dislike keeping duplicate files in
sync, especially when they might be changed manually
(e.g. ipa-getkeytab).
If we already almost anytime use a wrapper it might be less error prone.
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).
That works for regular starts. But - what if the keytab gets refreshed
at runtime or an expired certificate gets refreshed? For the cert I'd
like to see automatic refreshes...
> 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.
I have no idea if that works. Thanks for the hints above - I'll
experiment with it and let you know what I've learned.
> 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.
Great! Thanks for opening the issue and tracking it.
> 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.
Yes, that's something I've already done - this is on Debian:
Request ID '20180303211659':
status: MONITORING
stuck: no
key pair storage:
type=FILE,location='/etc/ssl/private/<hostname>.key'
certificate: type=FILE,location='/etc/ssl/certs/<hostname>.pem'
CA: IPA
issuer: CN=Certificate
Authority,O=EXAMPLE.ORG
subject:
CN=<hostname>.example.org,O=EXAMPLE.ORG
expires: 2022-02-04 22:17:09 CET
dns: <
hostname>.jochen.org
principal name: cockpit/<hostname>.example.org(a)EXAMPLE.ORG
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: sed -n w/etc/cockpit/ws-certs.d/50-from-certmonger.cert
/etc/ssl/certs/<hostname>.pem /etc/ssl/private/<hostname>.key
track: yes
auto-renew: yes
The certificate works fine in firefox.
Jochen
--
This space is intentionally left blank.