This is the second of two commits in a series that must be picked together.
This series of two commits moves parts of lib/krb5/ infrastructure
functionality to lib/base/, leaving behind wrappers.
Some parts of libkrb5 are entirely generic or easily made so, and could
be useful in various parts of Heimdal that are not specific to the krb5
API, such as:
- lib/gssapi/ (especially since the integration of NegoEx)
- lib/hx509/
- bx509d (which should really move out of kdc/)
For the above we need to move these bits of lib/krb5/:
- lib/krb5/config_file.c (all of it, leaving forwardings behind)
- lib/krb5/config_reg.c (all of it)
- lib/krb5/plugin.c (all of it, leaving forwardings behind)
- lib/krb5/log.c (all of it, ditto)
- lib/krb5/heim_err.et (all of it)
And because of those two, these too must also move:
- lib/krb5/expand_path.c (all of it, leaving forwardings behind)
- lib/krb5/warn.c (just the warning functions, ditto)
The changes to the moved files are mostly quite straightforward and are
best reviewed with --word-diff=color.
We're also creating a heim_context and a heim API to go with it. But
it's as thin as possible, with as little state as necessary to enable
this move. Functions for dealing with error messages use callbacks.
Moving plugin.c does have one knock-on effect on all users of the old
krb5 plugin API (which remains), which is that a global search and
replace of struct krb5_plugin_data to struct heim_plugin_data was
needed, though the layout and size of that structure doesn't change, so
the ABI doesn't either.
As well, we now build lib/vers/ and lib/com_err/ before lib/base/ so as
to be able to move lib/krb5/heim_err.et to lib/base/ so that we can make
use of HEIM_ERR_* in lib/base/, specifically in the files that moved.
Once this is all done we'll be able to use config files and plugins in
lib/hx509/, we'll be able to move bx509d out of kdc/, and so on.
Most if not all of the new functions in lib/base/ are Heimdal-private,
thus calling conventions for them are not declared.
Status:
- builds and passes CIs (Travis, Appveyor)
- ran make check-valgrind and no new leaks or other memory errors
- ready for review
HOW TO REVIEW:
$ # Review file moves:
$ git log --stat -n1 HEAD^
$
$ # Review changes to moved files using --word-diff=color
$ git log -p -b -w --word-diff=color HEAD^..HEAD \
lib/base/config_file.c \
lib/base/config_reg.c \
lib/base/expand_path.c \
lib/base/warn.c \
lib/krb5/config_file.c \
lib/krb5/config_reg.c \
lib/krb5/expand_path.c \
lib/krb5/warn.c
$
$ # Review the whole thing, possibly adding -b and/or -w, and
$ # maybe --word-diff=color:
$ git log -p origin/master..HEAD
$ git log -p -b -w origin/master..HEAD
$ git log -p -b -w --word-diff=color origin/master..HEAD
TBD (future commits):
- make lib/gssapi use the new heimbase functions
- move kx509/bx509d common code to lib/hx509/ or other approp. location
- move bx509d out of kdc/
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
The header file was not installed, and the manpage had the wrong
name for the plugin load function, it is "krb5_plugin_kuserok_plugin_load",
not "kuserok_plugin_load".
depending what's available when you compile for iOS it's possible to
be __APPLE__ and not have CF; actually test for it instead of blythely
assuming it can be used
For consistency make "-I" part of the macro value set by autoconf.
For now, don't attempt to handle OpenSSL rpath in cf/crypto.m4.
That's much easier by just setting LDFLAGS when running configure.
Otherwise too many Makefiles to edit and libtool and automake do
their best to undo the rpath.
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.
On Windows a file descriptor is an int value allocated by the
local module instance of the C Run Time Library. A socket handle is a
SOCKET value allocated by a Winsock Provider for the requested family and
protocol. These two values cannot be mixed and there is no mechanism for
converting between the two. The _get_osfhandle() and _open_osfhandle()
functions can work with a standard HANDLE (file, pipe, etc) but cannot be
used for a SOCKET.
The Heimdal krb5_storage_from_fd() routine counted on the osf conversion
functions working on SOCKET values. Since they do not any attempt to call
krb5_storage_from_fd() on a socket resulted in an assertion being thrown
by the C RTL.
Another problem is SOCKET value truncation when storing a 64-bit value
into a 32-bit int.
To address these problems a new krb5_storage_from_socket() routine is
introduced. This routine setups a krb5_storage that stores a socket value
as a rk_socket_t and provides a set of helper routines that always use
network ready functions.
The krb5_storage_from_fd() routines no longer use net_read() and
net_write() but provide helpers that follow their logic so that pipes can
be processed.
All call sites that allocate a socket now store the socket as rk_socket_t
and call krb5_storage_from_socket().
All locations that previously called the bare close() on a socket value
now call rk_closesocket().
Change-Id: I045f775b2a5dbf5cf803751409490bc27fffe597
To stop the errors when building concurrently, we make a number of
changes:
1. stop including generated files in *_SOURCES,
2. make *-protos.h and *-private.h depend on the *_SOURCES,
3. make all objects depend on *-{protos,private}.h,
4. in a few places change dir/header.h to $(srcdir)/dir/header.h,
This appears to work for me with make -j16 on a 4-way box.
krb5_enomem() is a wrapper around krb5_set_error_message() which
is used throughout the lib/krb5 sources. Some of the lib/krb5
sources are imported into third party projects and those projects
must be able to pull in krb5_enomem() without other baggage.
Create a new source file lib/krb5/enomem.c.
Change-Id: Id109386d48e3e2988b705b82525adf4f1fa5ea98
[Code reviewed by Love Hörnquist Åstrand <lha@kth.se>]
Added heim_db_*() entry points for dealing with databases, and
make krb5_aname_to_localname() use it.
The following enhancements to libheimbase are included:
- Add heim_data_t and heim_string_t "reference" variants to
avoid memory copies of potentially large data/strings.
See heim_data_ref_create() and heim_string_ref_create().
- Added enhancements to heim_array_t to allow their use for
queues and stacks, and to improve performance. See
heim_array_insert_value().
- Added XPath-like accessors for heim_object_t. See
heim_path_get(), heim_path_copy(), heim_path_create(), and
heim_path_delete(). These are used extensively in the DB
framework's generic composition of ACID support and in the
test_base program
- Made libheimbase more consistent with Core Foundation naming
conventions. See heim_{dict, array}_{get, copy}_value() and
heim_path_{get, copy}().
- Added functionality to and fixed bugs in base/json.c:
- heim_serialize();
- depth limit for JSON parsing (for DoS protection);
- pretty-printing;
- JSON compliance (see below);
- flag options for parsing and serializing; these are needed
because of impedance mismatches between heim_object_t and
JSON (e.g., heim_dict_t allows non-string keys, but JSON
does not; heimbase supports binary data, while JSON does
not).
- Added heim_error_enomem().
- Enhanced the test_base program to test new functionality and
to use heim_path*() to better test JSON encoding. This
includes some fuzz testing of JSON parsing, and running the
test under valgrind.
- Started to add doxygen documentation for libheimbase (but doc
build for libheimbase is still incomplete).
Note that there's still some incomplete JSON support:
- JSON string quoting is not fully implemented;
- libheimbase lacks support for real numbers, while JSON has
it -- otherwise libheimbase is a superset of JSON,
specifically in that any heim_object_t can be a key for an
associative array.
The following DB backends are supported natively:
- "sorted-text", a binary search of sorted (in C locale), flat
text files;
- "json", a backend that stores DB contents serialized as JSON
(this is intended for configuration-like contents).
The DB framework supports:
- multiple key/value tables per-DB
- ACID transactions
The DB framework also natively implements ACID transactions for
any DB backends that a) do not provide transactions natively, b)
do provide lock/unlock/sync methods (even on Windows). This
includes autocommit of DB updates outside transactions.
Future DB enhancements may include:
- add backends for various DB types (BDB, CDB, MDB, ...);
- make libhdb use heim_db_t;
- add a command-line tool for interfacing to databases via
libheimbase (e.g., to get/set/delete values, create/copy/
backup DBs, inspect history, check integrity);
- framework-level transaction logging (with redo and undo
logging), for generic incremental replication;
- framework-level DB integrity checking.
We could store a MAC of the XOR of a hash function applied to
{key, value} for every entry in the DB, then use this to check
DB integrity incrementally during incremental replication, as
well as for the whole DB.
NOTE: The test runs and succeeds, but the client seems to be getting
a new x-realm TGT after we set the kvno to 0 or remove the
kvno from the tickets. This means we're not really testing
the TGS paths! So this test is not yet ready.
Added to 11 out of 14 directories with map files. Not lib/ntlm,
lib/hcrypto and kdc which have the map file as an explicit dependency
to _OBBJECTS.
Signed-off-by: Love Hörnquist Åstrand <lha@h5l.org>
lib/krb5/crypto.c was a large, monolithic block of code which made
it very difficult to selectively enable and disable particular
alogrithms.
Reorganise crypto.c into individual files for each encryption and
salt time, and place the structures which tie everything together
into their own file (crypto-algs.c)
Add a non-installed library (librfc3961) and test program
(test_rfc3961) which builds a minimal rfc3961 crypto library, and
checks that it is usable.
