[redhat-lspp] SE Linux audit events

[Stephen Smalley]

On Tue, 2005-11-08 at 12:38 -0500, Steve Grubb wrote:
> Yes, I think any change to a trusted database needs to be recorded.

I agree - no argument on that point.

> Yes, it is more easily recognized for what it is. There is also a lot of extra 
> information that is not needed being sent. The majority of the syscall 
> information is not needed.

More easily recognized programmatically based on explicit message type,
yes.  The extra information problem seems like a general issue of
syscall info filtering, either in kernel or in userspace.

> Well, we need to have more than AVC's to represent what is going on in the 
> system. This is a configuration change, why not call it that?

We often need userspace level auditing to represent what is truly going
on in the system, e.g. the kernel can report policy reloads, but not
much of interest about what really changed in that policy.  We can then
use the kernel controls to ensure that the userspace components that
provide that auditing are unbypassable.  I do agree that you want kernel
auditing of the primitive events, but that alone won't give you the full
picture naturally.

With regard to "more than AVCs", we can represent quite a bit about what
is happening via the avc_audit_data supplemental information that is
used by avc_audit(), and that can be easily extended to show things like
the enforcing status on a setenforce check.  However, I agree that e.g.
for a boolean commit, converting the printk for showing all of the
booleans being committed that is already there into an avc audit would
be painful.  Converting such printks into calls to the audit system
makes sense.   I'm just not sure how much we gain from converting the
auditallows on setenforce, load_policy, and setbool over to direct audit
calls versus just adding supplemental data as desired to avc_audit_data.
The only real benefit seems to be making it easier to recognize
programmatically from other kinds of audit data, and perhaps that
justifies it.

> We have a boatload of changes going upstream, one more doesn't hurt.

One more change _can_ hurt.  If it isn't truly needed, then it takes
away time from tasks that are truly needed, and there seems to be no
shortage of tasks that need to be done for LSPP (not to mention the
tasks that are not directly related to LSPP but important to advancing
SELinux functionality).  "One more doesn't hurt" also lends itself to
bloat and feature creep.

-- 
Stephen Smalley
National Security Agency