When using the pkcshsm_mk_change tool to initiate a concurrent master
key change, it is important that all affected tokens are available and
that the user using the pkcshsm_mk_change tool has permissions to use all
tokens, i.e. the user should be part of all token groups.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
There are implementation-defined behaviours that need to be handled for various
UNIX platforms. For instance, the file locking featureset from BSD (`flock`)
requires the file to be opened in write mode on AIX, but Linux does not care
about the mode in which the file is opened. To preserve backward compatibility,
however, Linux retains its existing file mode; otherwise previous/leftover
daemon runs will cause future daemon startup failures - the lock can never be
obtained in the new file mode, because it will attempt to open a file with mode
bits `-r--` in write mode, which will never succeed (always returns `EPERM`).
There will be no difference to AIX because the open mode is still decided at
compile time, depending on the platform.
Dynamic token loading has also been changed, such that the symbols from all
token libraries are not visible in the process namespace anymore. This is
important because global symbol visibility affects the functionality that is
loaded - because each token exposes the same set of symbols, which have
differing behaviours based on the type of the token. The order in which the
tokens are specified in the configuration also makes a difference here, since
the token that was loaded first overrides the symbols that any later token
load provides. This basically means that all tokens that are not loaded first
do not have their symbols visible to the loading process, which means their
functions are never executed. Restricting the symbol visibility to the library
itself (`RTLD_LOCAL`) solves this issue.
IBM's xlc requires the `init` and `fini` functions to be specified on the
command-line, in addition to being specified as `pragma`s within the source
code. Furthermore, the format of the symbol export definition file differs
from that of gcc. xlc does not have semver support for shared libraries, and
therefore the export format file necessitates being different. This file is
therefore now generated dynamically during the configuration phase by an
(admittedly) hacky string manipulation within configure.ac. But it works(tm),
so it stays in until it breaks.
Signed-off-by: Akash Kulhalli <akash.kulhalli@ibm.com>
Headers not specified either in xxx_SOURCES or noinst_HEADERS will not
be included for 'make dist', and will cause compile errors during
'make distcheck'. Also include several extra files into EXTRA_DIST to
make sure they are distributed as well.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
The use of transactional memory has never really worked for openCryptoki.
Also, many code places use locks, even with '--disable-locks'.
Option '--enable-locks' has been the default so far.
To retain backward compatibility, continue to accept the '--disable-locks'
option during configuration, but ignore it if it is specified. A warning
message is issued if --disable-locks' is still used.
With this change, there is no longer a need to maintain 2 copies of the
btree.c and sess_mgr.c source (btree.c and lock_btree.c, sess_mgr.c and
lock_sess_mgr.c), which contained the same code except the differences for
supporting transactional memory versus locks. Now only the version with
locks is retained, but it is renamed to not contain the 'lock_' prefix any
more.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Only reference the .y and .l files in SOURCES, but not the generated .c
files.
Building the configuration parser requires own rules for yacc and lex.
Avoid automake target override warning using Wno-override.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Implement strength and policy parsing and enforce policies in all tokens. The
main object of the policy is the struct objstrength which carries the strength
of a key along with a flag specifying if the EC is allowed, and a (maximal)
signature length if this key is used to sign or verify and the length of the
signature depends on the key.
A valid strength configuration has to be found. If no policy configuration is
found, policies are simply deactivated and keys are only classified according
to the strength definition, but can be used without restrictions. If both, a
strength and a policy configuration, are available, both have to be valid for
OpenCryptoki to start. If either of these two configurations fails to parse
or validate, OpenCryptoki will fail with a general error since the system is
not in a valid state.
The configuration files have to be owned by root:pkcs11 and have to have modes
0640. This is done for security reasons to prevent anybody except root from
altering the policy or strength definitions.
Signed-off-by: Juergen Christ <jchrist@linux.ibm.com>
Add a single source mechanism table to be used by policy and other code. This
should remove the various tables and switches over mechanisms in the code and
provide a common way to translate between numeric and string representation.
Signed-off-by: Juergen Christ <jchrist@linux.ibm.com>
Create a separate library context for Opencryptoki's use of OpenSSL services
and explicitly load the 'default' provider for this context.
This prevents call-loops when the calling application has configured a PKCS#11
provider that uses Opencryptoki under the covers. This could produce a loop
with the following calling tree:
Application -> Openssl -> PKCS11-provider -> Opencryptoki -> OpenSSL
-> PKCS11-provider -> Opencryptoki -> ...
Explicitly using the 'default' provider only for Opencrypoki's OpenSSL usage
breaks this loop.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
