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.

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(a)schaufler-ca.com&gt; 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

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.