Differentiating audit rules in an LSM stack

[Steve Grubb]

On Friday, December 22, 2017 4:02:41 PM EST Paul Moore wrote:
> On Fri, Dec 22, 2017 at 3:01 PM, Casey Schaufler <casey at schaufler-ca.com> 
wrote:
> > The audit rule field types AUDIT_SUBJ_* and AUDIT_OBJ_* are
> > defined generically and used by both SELinux and Smack to identify
> > fields that are interesting to them. If SELinux and Smack are running
> > concurrently both modules will identify audit rules as theirs if
> > either has requested the field. Before I go off and create a clever
> > solution I think it wise to ask if anyone has thought about or has
> > strong opinions on how best to address this unfortunate situation.
> > 
> > We know that SELinux and Smack together is not an especially
> > interesting configuration. It is, however, a grand test case for
> > generality of the solution. Any module that wanted to audit fields
> > that are defined generically will have this sort of problem.
> 
> I think the biggest concern here is going to be what Steve's audit
> userspace will tolerate.  I might suggest simply duplicating the
> fields for each LSM that is running, e.g. "subj=<selinux_label>
> subj=<smack_label> subj=<lsmX_label> ...", but I have no idea if
> Steve's userspace can handle multiple instances of the same field in a
> single record.

That would be bad in general because we have a field dictionary that defines the 
value side of the field=value. Another alternative might be to prepend an lsm 
specific abbreviation? This keeps the field dictionary correct.

I originally thought we were talking about AVC's and reusing the same record type 
for the different LSM's. That would be simple to fix by just adding a "lsm=x" field at 
the beginning.

But if we are talking about each and every syscall or path record, I think this will 
make things ugly fast. I'd prefer prepending an identifier to the field name so that 
we can do LSM specific reporting. I have never seen or heard of a system that has a 
subject or object with multiple labels. We don't even include supplemental groups in 
syscall records and that is usually pretty important information.

> My initial thinking is that adding LSM-specific subj/obj fields would
> be a mistake.

How so? If someone wanted a selinux specific report, how else would you detangle 
which representation is selinux's?

-Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20180102/a11b57b4/attachment.htm>