[redhat-lspp] SE Linux audit events

[Stephen Smalley]

On Tue, 2005-11-08 at 10:49 -0500, Steve Grubb wrote:
> On Tuesday 08 November 2005 10:38, Stephen Smalley wrote:
> > Already handled by auditallow rules on load_policy permission.  As
> > above, I don't see a need for a distinct audit type when we have a
> > distinct permission.
> 
> I think these need to be hardwired into the kernel so that they can't be 
> deleted accidentally or maliciously. Also, if the system is booted in 
> non-enforcing mode, how does that fact get into the audit system?

Accidental or malicious deletion of such audit rules is no less
dangerous than accidental or malicious deletion of the allow rules, so
I'm not sure why it needs to differ in its handling.  Proper protection
of the policy is necessary in either case.  With regard to initial boot
state, SELinux reports that via printk in selinux_init(); naturally, it
can't use the audit system at that point.  The resulting message shows
up in dmesg and /var/log/messages.  Even if we used the audit
interfaces, they would fall back to using printk since auditd isn't
around at that point.

BTW, SELinux already broadcasts a message via a netlink socket for
setenforce changes (with the enforcing value) and for policy loads (with
the sequence number) for use by the libselinux AVC, so auditd could
listen for those messages as well if desired.

> Are there other events that we care about besides those three?

selinux_disable(), I suppose.  It presently does a printk as well.  Can
only occur prior to initial policy load by /sbin/init, so auditd isn't
alive yet.

-- 
Stephen Smalley
National Security Agency