[redhat-lspp] SE Linux audit events

[Steve Grubb]

On Tuesday 08 November 2005 10:58, Stephen Smalley wrote:
> 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.

Just to make sure these events get recorded no matter what the policy says. I 
think the auditallow rules can stay in the policy if there's some real reason 
to keep them. But you are already using the audit system to record avc 
messages, why would you object to continuing using the audit system but have 
the config change events formalized? Seems like its no harm done to SE Linux 
and helps make these type of things stand out better in log analysis.

> 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.

I know. This is a problem we need to solve. There are some other things that 
happen at boot that I think needs to be spooled and dumped to syslog only 
when it appears auditd will never show up.

> 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.

I think we want more information than comes down the selinux socket. We want 
auid, prev & new values, success/fail. We need this to obey the global config 
rules for the audit system as well. -e, -b, -f, so I don't think this is the 
best option.

> > 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.

I was thinking this might fit under MAC_STATUS_CHANGE.

-Steve