<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"> <html><head><meta name="qrichtext" content="1" /><style type="text/css"> p, li { white-space: pre-wrap; } </style></head><body style=" font-family:'Cantarell'; font-size:15pt; font-weight:400; font-style:normal;"> 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@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</body></html>