Difference between revisions of "NB AL"

(New page: = Audit Logs = For SELinux there are two main types of audit event: # SELinux-aware Application Events - These are generated by the SELinux kernel services and SELinux-aware applications ...)

Revision as of 15:06, 16 May 2010

Audit Logs

SELinux-aware Application Events - These are generated by the SELinux kernel services and SELinux-aware applications for events such as system errors, initialisation, policy load, changing boolean states, setting of enforcing / permissive mode and relabeling.

AVC Audit Events - These are generated by the AVC subsystem as the result of access denials, or where specific events have requested an audit message (i.e. where an auditallow rule has been used in the policy).

The audit and event messages can be stored in one of two places (in F-12 anyway):

The system log located at /var/log/messages that contains the syslog boot and runtime events. The AVC messages logged here are those generated by SELinux before the audit daemon has been loaded, as F-12 uses the audit framework (auditd) as standard. However, some SELinux-aware audit messages are logged here as well[1]. Note that the detailed SELinux kernel boot events are logged in the /var/log/dmesg file.

The audit log located at /var/log/audit/audit.log. Audit events that take place after the audit daemon has been loaded are in this log file as are some SELinux system messages. The AVC audit messages of interest are those starting with type=AVC and are described below.

Note that SE-PostgreSQL does not send its AVC events to the standard audit.log, but to its own log file as discussed in the SELinux PostgreSQL Support section.

SELinux-aware Application Events

For SELinux and SELinux-aware applications (excluding the AVC entries that are discussed in the AVC Audit Events section below) the following are possible type= entries within the audit.log file that have been seen:

This will contain the audit keyword with a reference number (e.g. msg=audit(1243332701.744:101))

avc

This will be either denied when access has been denied or granted when the auditallow rule has been executed by the AVC system.

The entries that follow the avc= field depend on what type of event is being audited. Those shown below are generated by the kernel AVC audit function, however the user space AVC audit function will return fields relevant to the application being managed by their Object Manager.

pid

If a task, then log the process id (pid) and the name of the executable file (comm).

comm

key

If an IPC event then log the identifier.

capability

If a Capability event then log the identifier.

path

If a File System event then log the relevant information. Note that the name field may not always be present.

name

dev

ino

laddr

If a Socket event then log the Source / Destination addresses and ports for IP4 or IP6 sockets (AF_INET).

lport

faddr

fport

path

If a File Socket event then log the path (AF_UNIX).

saddr

If a Network event then log the Source / Destination addresses and ports with the network interface for IP4 or IP6 networks (AF_INET).

src

daddr

dest

netif

sauid

IPSec security association identifiers

hostname

addr

terminal

resid

X-Windows resource ID and type.

restype

scontext

The security context of the source or subject.

tcontext

The security context of the target or object.

tclass

The object class of the target or object.

Table 4: AVC Audit Message Description - The keywords in bold are in all AVC audit messages, the others depend on the type of event being audited.

Example audit.log denied and granted events are shown in the following examples:

↑For example if the iptables are loaded and there are SECMARK security contexts present, BUT the contexts are invalid (i.e. not in the policy), then the event is logged in the messages log and nothing will appear in the audit log.