[patch RFC]: userspace crypto auditing, v2

[Miloslav Trmac]

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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: audit-examples.txt
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20100901/0260ad57/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kernel.patch
Type: text/x-patch
Size: 14264 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20100901/0260ad57/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: audit-2.0.4-userspace_crypto.patch
Type: text/x-patch
Size: 9790 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20100901/0260ad57/attachment-0001.bin>