Hello, I'm posting these patches for early review again; users of the code are not in the kernel yet. Changes since the previous version: - New record type CRYPTO_AUDIT_CRYPTO_KEY_VALUE, to implement "basic" level from CC - aureport handles events with multiple crypto records Record types ------------ This patch set keeps the original single AUDIT_CRYPTO_USERSPACE_OP record type. Here is a description of all kinds of events that can happen, to facilitate discussion of the requested record types. The following events cause creation of a CRYPTO_USERSPACE_OP record: * context_new: A new "crypto context" (within which integer IDs are allocated) was set up. Fields: context ID * context_del: A crypto context was destroyed. Fields: context ID * key_wrap: A key was wrapped using another key Fields: context ID, wrapping algorithm name, [wrapping key], wrapped key If wrapping key is not explicitly recorded, it is the storage master key * key_unwrap: A key was unwrapped using another key Fields: context ID, wrapping algorithm name, [wrapping key], wrapped key If wrapping key is not explicitly recorded, it is the storage master key * key_export: Key material was written to userspace Fields: context ID, key algorithm, key * key_import: Key material was read from userspace Fields: context ID, key algorithm, key * key_zeroize: Key object was cleared Fields: context ID, key algorithm, key CRYPTO_KEY_VALUE record may follow * key_gen: A key or key pair was generated Fields: context ID, key algorithm, key, [public key] One or two CRYPTO_KEY_VALUE records may follow * key_get_info: Information about a key was provided to userspace Fields: context ID, key algorithm, key * key_derive: A new key was derived from an existing key Fields: context ID, key algorithm, source key, new key * session_init: A new crypto operation context was created Fields: context ID, [session ID], operation name, algorithm, [key] session ID is missing for sessions that do not span more than one system call * session_op: An operation within a session was performed Fields: context ID, [session ID], operation name, algorithm, [input key] * session_final: A session was finished Fields: context ID, [session ID], operation name, algorithm In all of the above, "key" in Fields means "integer key ID, longer-term ID byte string". Looking at the record types proposed earlier, AUDIT_CRYPTO_STORAGE_KEY could perhaps use AUDIT_CRYPTO_PARAM_CHANGE_KERN, and all of the key_* events above can use AUDIT_CRYPTO_KEY_KERN. There is no good match for the session_* events. I also think the KEY_VALUE data should use separate records to allow filtering them out while keeping the rest of the information - see below for rationale. Patch description ----------------- Three new records are defined; in each case output of records is caused by a syscall, and all other syscall-related data (process identity, syscall result) is audited in the usual records. AUDIT_CRYPTO_STORAGE_KEY is used when a system-wide storage wrapping key is changed. AUDIT_CRYPTO_USERSPACE_OP is used when any user-space program performs a crypto operation. To disable auditing these records by default and to allow the users to selectively enable them using filters, a new filter field AUDIT_CRYPTO_OP is defined; auditing of all crypto operations can thus be enabled using (auditctl -a exit,always -F crypto_op!=0). AUDIT_CRYPTO_KEY_VALUE is used to record public key components when generating or zeroizing keys (as required for CC "basic" level auditing). The CRYPTO_KEY_VALUE record always immediately follows a CRYPTO_USERPACE_OP record that describes the performed operation. Unfortunately the key components can be quite large (a 4096-bit value results in a 1kB field in the record), but there does not seem to be any way to avoid this. It would probably be possible, as an optimization, to skip creating these records if the *_KEY_VALUE type is filtered out (-a type,never). Attached for review are: - A kernel patch - An userspace audit patch - A few example audit entries Mirek