Project proposal

Remote Audit Trail Storage - the project proposal

Motivation

Secure and reliable transmission and storage of audit records via (encrypted)
TCP stream. Currently, the existing deployment of the NFS as a remote audit
trail storage is not sufficient. audit_syslog(5) plugin which sends audit
records to syslog is not the solution either.

Architecture

Components:

1. auditd plugin capable of sending the audit records via tcp to the remote server.
2. remote audit server raudit which listens on network, validates and stores received data.

Audit plugins: audit_remote

Operation:

Each received record (via private interface auditd~_plugin()) is forwarded via
a tcp connection to the remote audit server. Stream consists of successive
sequence of record length token and record itself. 

If sending fails or connection is not established, a plugin will try to
open/send again for a predefined number of times and then try to send a record
to the next configured host. If all attempts to send a record to any of the
remote hosts fails, the plugin will enforce audit policy (eg. dropping records
if policy is 'cnt' or halting system if policy is 'hlt').
auditd~_plugin() implementation can be called from several threads so it has
to ensure appropriate locking.

Configuration:

Configuration similar to audit~_binfile, ie. via audit~_control(4):

Attributes:

• hosts - list of remote hosts (in host:port format)
• retries - how many times to try resending event/opening connection
• timeout - tcp connection timeout

Remote audit service: raudit

Operation:

Listens on the configured tcp port, verifies incoming data and writes
to audit trail.

Configuration and Supervision:

rauditd is managed by smf(5) framework. Configuration is similar to auditd(1m) but is stored in the smf repository.

Multiple directories can be configured (as per audit_binfile) and raudit will automatically create a subdirectory for each host where it writes audit trails. 

Eg. let's have 

                        dir:/var/audit
                        dir:/z1/audit
                        dir:/z2/audit

then the structure will be:

                        /var/audit/host1/
                        /var/audit/host2/
                        ...
                        /var/audit/hostn/

                        /z1/audit/host1/
                        /z1/audit/host2/
                        ...
                        /z1/audit/hostn/

                        /z2/audit/host1/
                        ...
                        /z2/audit/host2/
                        /z2/audit/hostn/

Attributes (and their corresponding scf types):

• dir:astring_list - list of audit trail directories
• maxclients:count - maximum number of audited hosts
• minfree:count - soft limit value (see audit_control(4))
• port:count - tcp listening port

Security

GSS-API is used both for client authentication to the raudit server and data encryption. Implementation is GSS mechanism agnostic so either Kerberos or pubkey mechanism can be used out of box depending on the GSS configuration in /etc/gss/mech.

Backpressure/policy enforcement

1. Network outage/raudit outage - For short outages, audit plugins will try to resent audit records, for longer outages they will enforce audit policy configured for each host.
2. Traffic congestion/heavy load of raudit server - current implementation slows down/blocks processes if all threads calling audit_plugin() block
           

Related RFEs/proposals

• 6376592 need audit plugin to send full audit records to a remote server
• 4009451 need mechanism for putting audit trail on remote machine

Sources & Webrevs

Preliminary patches against ON sources are in /hg/audit/patches repository:

• audit_tcp.patch - audit_remote tcp plugin
• rauditd.patch - remote audit server