backends
When running with verify-password-quality and a back-end that stores
history (such as heimdal-history) this command can cause an update to
the database meaning the password can no longer be used with this
principal in the future
At one point in time, the configuration option was named
"password-quality" but this was later changed to
"verify-password-quality". Update the kadmin(1) man page to reflect
this change.
warning: incompatible pointer types passing 'int *' to parameter
of type 'size_t *' (aka 'unsigned long *') [-Wincompatible-pointer-types]
Change-Id: Id75b1b1c9b46b63ab61134f4f91b7c2909d87077
Coverity determined that a NULL pointer segmentation fault could occur
if krb5_storage_emem() fails. Use krb5_enomem() to set an error message
on the context and do not perform further krb5_storage operations.
Change-Id: I9587208e46c184bb061443a44581a32dd722de33
- Add --keepold/keepallold/pruneall options to various kadmin/ktutil
commands. Default behavior to "prune old keys".
- When setting keys for a service, we need to specify enctypes for it:
- Always use kadm5_randkey_principal_3() instead of the older
kadm5_randkey_principal().
- Add krb5_string_to_keysalts2(), like MIT's krb5_string_to_keysalts(),
but with a context, and simpler.
- Add --enctypes options to various kadmin/ktutil commands.
- Add [libdefaults] supported_enctypes param with enctype[:salttype]
list.
- Add [realms] realm supported_enctypes param with enctype[:salttype]
list.
Default to aes128-cts-hmac-sha1-96:normal.
Since c6bf100b password quality checks have been moved out of kadmindd and into
libkadm5. This means that all password changes are subject to quality checks,
if enforce_on_admin_set is true (the default). In rare instances it could be
possible for realm initialization to fail because the randomly generated
passwords do not pass the password quality test. Fix this by creating
principals with no password or key, rather than with a random password.
Random *keys* continue to be set immediately after the principal is created,
and before DISALLOW_ALL_TIX is unset, so there should be no functionality or
security implications from this change. It is safe to call a server-side API
such as kadm5_s_create_principal_with_key() as local_flag is asserted to be
true.
Since c6bf100b password quality checks have been moved out of kadmindd and into
libkadm5. This means that all password changes are subject to quality checks,
if enforce_on_admin_set is true (the default). In rare instances it could be
possible for realm initialization to fail because the randomly generated
passwords do not pass the password quality test. Fix this by creating
principals with no password or key, rather than with a random password.
Random *keys* continue to be set immediately after the principal is created,
and before DISALLOW_ALL_TIX is unset, so there should be no functionality or
security implications from this change. It is safe to call a server-side API
such as kadm5_s_create_principal_with_key() as local_flag is asserted to be
true.
Note that this has a slight behavior change to c89d3f3b in order to continue
allow kadmin in local mode to bypass password quality checks. Password quality
checks are always bypassed if the *client* kadmin principal is kadmin/admin,
i.e. that of the kadmin service itself. This is the case when running kadmin in
local mode. As this is the equivalent of a superuser account, one would
anticipate that deployments would use specific administrator instances for
appropriate ACLs for day-to-day administration; operations by these will be
subject to password quality checks if enforce_on_admin_set is TRUE, or if the
user is changing their own password.
This patch adds the "enforce_on_admin_set" configuration knob in the
[password_quality] section. When this is enabled, administrative password
changes via the kadmin or kpasswd protocols will be subject to password quality
checks. (An administrative password change is one where the authenticating
principal is different to the principal whose password is being changed.)
Note that kadmin running in local mode (-l) is unaffected by this patch.
Using non-reentrant getpwuid() (or getpwnam(), or getspnam()) can be
dangerous. We had a report of a login application / PAM that calls
those, and Heimdal, by calling them too, clobbered the cached struct
passwd used by the login app / PAM.
Adding a principal with a random key or password did not respect non-default
password expiration times, because the act of setting the key or password would
clobber it with the default. As we update the principal anyway after setting
the keys, use this opportunity to restore the requested password expiration
time. (There are other ways to solve this, but this is the least intrusive.)
When the master's log has all entries from version 1 to now, and no
uber entry (legacy master), then new slaves will not pull version 1,
because their uber record has version 1.
The fix is to force the uber version to 0 always, and avoid adding a
truncate nop when doing a full prop. The uber record now records the
database version even in the absence of any other log entries so that
we know what to pull going forward.
This adds a new backend for libhcrypto: the OpenSSL backend.
Now libhcrypto has these backends:
- hcrypto itself (i.e., the algorithms coded in lib/hcrypto)
- Common Crypto (OS X)
- PKCS#11 (specifically for Solaris, but not Solaris-specific)
- Windows CNG (Windows)
- OpenSSL (generic)
The ./configure --with-openssl=... option no longer disables the use of
hcrypto. Instead it enables the use of OpenSSL as a (and the default)
backend in libhcrypto. The libhcrypto framework is now always used.
OpenSSL should no longer be used directly within Heimdal, except in the
OpenSSL hcrypto backend itself, and files where elliptic curve (EC)
crypto is needed.
Because libhcrypto's EC support is incomplete, we can only use OpenSSL
for EC. Currently that means separating all EC-using code so that it
does not use hcrypto, thus the libhx509/hxtool and PKINIT EC code has
been moved out of the files it used to be in.
CVE-2016-2400
kadmind(8) was not checking for 'add' permission to aliases added via
kadm5_modify_principal(). This is a security vulnerability. The impact
of this vulnerability is mostly minor because most sites that use
kadmind(8) generally grant roughly the same level of permissions to all
administrators. However, the impact will be higher for sites that grant
modify privileges to large numbers of less-privileged users.
From what we know of existing deployments of Heimdal, it seems very
likely that the impact of this vulnerability will be minor for most
sites.
We used to update the iprop log and HDB in different orders depending on
the kadm5 operation, which then led to various race conditions.
The iprop log now functions as a two-phase commit (with roll forward)
log for HDB changes. The log is auto-truncated, keeping the latest
entries that fit in a configurable maximum number of bytes (defaults to
50MB). See the log-max-size parameter description in krb5.conf(5).
The iprop log format and the protocol remain backwards-compatible with
earlier versions of Heimdal. This is NOT a flag-day; there is NO need
to update all the slaves at once with the master, though it is advisable
in general. Rolling upgrades and downgrades should work.
The sequence of updates is now (with HDB and log open and locked):
a) check that the HDB operation will succeed if attempted,
b) append to iprop log and fsync() it,
c) write to HDB (which should fsync()),
d) mark last log record committed (no fsync in this case).
Every kadm5 write operation recover transactions not yet confirmed as
committed, thus there can be at most one unconfirmed commit on a master
KDC.
Reads via kadm5_get_principal() also attempt to lock the log, and if
successful, recover unconfirmed transactions; readers must have write
access and must win any race to lock the iprop log.
The ipropd-master daemon also attempts to recover unconfirmed
transactions when idle.
The log now starts with a nop record whose payload records the offset of
the logical end of the log: the end of the last confirmed committed
transaction. This is kown as the "uber record". Its purpose is
two-fold: act as the confirmation of committed transactions, and provide
an O(1) method of finding the end of the log (i.e., without having to
traverse the entire log front to back).
Two-phase commit makes all kadm5 writes single-operation atomic
transactions (though some kadm5 operations, such as renames of
principals, and changes to principals' aliases, use multiple low-level
HDB write operations, but still all in one transaction). One can still
hold a lock on the HDB across many operations (e.g., by using the lock
command in a kadmin -l or calling kadm5_lock()) in order to push
multiple transactions in sequence, but this sequence will not be atomic
if the process or host crashes in the middle.
As before, HDB writes which do not go through the kadm5 API are excluded
from all of this, but there should be no such writes.
Lastly, the iprop-log(1) command is enhanced as follows:
- The dump, last-version, truncate, and replay sub-commands now have an
option to not lock the log. This is useful for inspecting a running
system's log file, especially on slave KDCs.
- The dump, last-version, truncate, and replay sub-commands now take an
optional iprop log file positional argument, so that they may be used
to inspect log files other than the running system's
configured/default log file.
Extensive code review and some re-writing for clarity by Viktor Dukhovni.
