[Heimdal-source-changes] [heimdal/heimdal] d31dd9: hx509: make file store writes atomic

Nico Williams noreply at github.com
Ons Okt 9 05:20:00 CEST 2019


  Branch: refs/heads/master
  Home:   https://github.com/heimdal/heimdal
  Commit: d31dd9e00be371a2e763a51e7c7526f6da99ba76
      https://github.com/heimdal/heimdal/commit/d31dd9e00be371a2e763a51e7c7526f6da99ba76
  Author: Nicolas Williams <nico at twosigma.com>
  Date:   2019-10-08 (Tue, 08 Oct 2019)

  Changed paths:
    M lib/hx509/ks_file.c

  Log Message:
  -----------
  hx509: make file store writes atomic

Now we'll use mkostemp() and rename() into place to make
hx509_certs_store() atomic for FILE/DER-FILE/PEM-FILE stores.

This is not ideal, as it can leave temp files in place if a process
crashes in between the mkostemp() and the rename into place.

On Linux we'll eventually make use of O_TMPFILE and linkat().  The idea
will be to first create an anonymous, zero-link file in the directory
that will contain the file at the end, write the file, then linkat() the
file into place as a .new file, then rename() the .new into place.  That
will limit the amount of junk that may be left behind to just one file.
(If the linkat() fails, then unlink() the .new and try again.  If the
rename() fails that just means the caller raced with another and the
operation is complete.)

We should really make a lib/roken interface that does this.


  Commit: 78cb995e6e6d744f3b8f036f4e62e7ccc693454e
      https://github.com/heimdal/heimdal/commit/78cb995e6e6d744f3b8f036f4e62e7ccc693454e
  Author: Nicolas Williams <nico at twosigma.com>
  Date:   2019-10-08 (Tue, 08 Oct 2019)

  Changed paths:
    M lib/krb5/version-script.map

  Log Message:
  -----------
  krb5: add missing export


  Commit: 6a7e7eace67cb3021bcd6dce3a2ff80e6dff76d1
      https://github.com/heimdal/heimdal/commit/6a7e7eace67cb3021bcd6dce3a2ff80e6dff76d1
  Author: Nicolas Williams <nico at twosigma.com>
  Date:   2019-10-08 (Tue, 08 Oct 2019)

  Changed paths:
    A doc/standardisation/rfc6717.txt
    M kdc/default_config.c
    M kdc/kx509.c
    M kdc/process.c
    M kuser/Makefile.am
    M kuser/NTMakefile
    M kuser/heimtools-commands.in
    M kuser/klist.1
    M kuser/klist.c
    M lib/asn1/kx509.asn1
    M lib/krb5/Makefile.am
    M lib/krb5/NTMakefile
    M lib/krb5/cache.c
    M lib/krb5/krb5.conf.5
    M lib/krb5/krb5.h
    A lib/krb5/kx509.c
    A lib/krb5/kx509_err.et
    M lib/krb5/libkrb5-exports.def.in
    M lib/krb5/version-script.map
    M tests/gss/krb5.conf.in
    M tests/kdc/Makefile.am
    M tests/kdc/check-pkinit.in
    M tests/kdc/krb5-pkinit.conf.in

  Log Message:
  -----------
  Add kx509 client and revamp kx509 service

This commit adds support for kx509 in libkrb5, and revamps the KDC's
kx509 service (fixing bugs, adding features).

Of note is that kx509 is attempted optimistically by the client, with
the certificate and private key stored in the ccache, and optionally in
an external PEM or DER file.

NOTE: We do not optimistically use kx509 in krb5_cc_store_cred() if the
      ccache is a MEMORY ccache so we don't generate a key when
      accepting a GSS context with a delegated credential.

kx509 protocol issues to be fixed in an upcoming commit:

 - no proof of possession (this is mostly not too bad, but we'll want to
   fix it by using CSRs)
 - no algorithm agility (only plain RSA is supported)
 - very limited (no way to request any options in regards to the
   requested cert)
 - error codes are not very useful

Things we're adding in this commit:

 - libkrb5 kx509 client
 - automatic kx509 usage hooked in via krb5_cc_store_cred() of start TGT
 - per-realm templates on the KDC side
 - per-realm issuer certificates
 - send error messages on the KDC side
   (this is essential to avoid client-side timeouts on error)
 - authenticate as many error messages
 - add a protocol probe feature so we can avoid generating a
   keypair if the service is not enabled
   (once we add support for ECC algorithms we won't need this
    anymore; the issue is that RSA keygen is slow)
 - support for different types of client principals, not just username:

    - host-based service and domain-based service, each with its own
      template set per-{realm, service} or per-service

   (the idea is to support issuance of server certificates too, not
    just client/user certs)
 - more complete support for SAN types
 - tests (including that PKINIT->kx509->PKINIT works, which makes it
   possible to have "delegation" of PKIX credentials by just delegating
   Kerberos credentials)
 - document the protocol in lib/krb5/kx509.c

Future work:

 - add option for longer-ticket-lifetime service certs
 - add support for ECDSA, and some day for ed25519 and ed448
 - reuse private key when running kinit
   (this will require rethinking how we trigger optimistic kx509
    usage)
 - HDB lookup for:
    - optional revocation check (not strictly necessary)
    - adding to certificates those SANs listed in HDB
       - hostname aliases (dNSName SANs)
       - rfc822Name (email)
       - XMPP SANs
       - id-pkinit-san (a user could have aliases too)
 - support username wild-card A RRs, ala OSKT/krb5_admin
    i.e., if a host/f.q.d.n principal asks for a certificate for
    some service at some-label.f.q.d.n, then issue it
   (this is not needed at OSKT sites because OSKT already
    supports keying such service principals, which means kx509
    will issue certificates for them, however, it would be nice
    to be able to have this independent of OSKT)
   (a better way to do this would be to integrate more of OSKT
    into Heimdal proper)
 - a kx509 command, or heimtools kx509 subcommand for explicitly
   attempting use of the kx509 protocol (as opposed to implicit, as is
   done in kinit via krb5_cc_store_cred() magic right now)

Issues:

 - optimistically trying kx509 on start realm TGT store -> timeout issues!
    - newer KDCs will return errors because of this commit; older ones
      will not, which causes timouts
    - need a separate timeout setting for kx509 for optimistic case
    - need a [realm] config item and DNS SRV RR lookup for whether a
      realm is expected to support kx509 service


Compare: https://github.com/heimdal/heimdal/compare/098f6480e463...6a7e7eace67c


More information about the Heimdal-source-changes mailing list