Differentiating audit rules in an LSM stack
From: paul@paul-moore.com (Paul Moore)
Date: 2017-12-22 21:02:41
On Fri, Dec 22, 2017 at 3:01 PM, Casey Schaufler [off-list ref] 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. My initial thinking is that adding LSM-specific subj/obj fields would be a mistake. -- paul moore www.paul-moore.com -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html