Re: Preferred subj= with multiple LSMs

On Mon, Jul 15, 2019 at 6:56 PM Steve Grubb <sgrubb(a)redhat.com&gt; wrote: > On Monday, July 15, 2019 5:28:56 PM EDT Paul Moore wrote: >> On Mon, Jul 15, 2019 at 3:37 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; > wrote: >>> On 7/15/2019 12:04 PM, Richard Guy Briggs wrote: >>>> On 2019-07-13 11:08, Steve Grubb wrote: ... >>>> Steve's answer is the obvious one, ideally allocating a seperate range >>>> to each LSM with each message type having its own well defined format. >>> It doesn't address the issue of success records, or records >>> generated outside the security modules. >> Yes, exactly. The individual LSM will presumably will continue to >> generate their own audit records as they do today and I would imagine >> that the subject and object fields could remain as they do today for >> the LSM specific records. >> >> The trick is the other records which are not LSM specific but still >> want to include subject and/or object information. Unfortunately we >> are stuck with some tough limitations given the current audit record >> format and Steve's audit userspace tools; > Not really. We just need to approach the problem thinking about how to make > it work based on how things currently work. I suppose it is all somewhat "subjective" - bad joke fully intended :) - with respect to what one considers good/bad/limiting. My personal view is that an ideal solution would allow for multiple independent subj/obj labels without having to multiplex on a single subj/obj field. My gut feeling is that this would confuse your tools, yes? > For example Casey had a list of possible formats. Like this one: > > Option 3: > lsms=selinux,apparmor subj=x:y:z:s:c subj=a > > I'd suggest something almost like that. The first field could be a map to > decipher the labels. Then we could have a comma separated list of labels. > > lsms=selinux,apparmor subj=x:y:z:s:c,a Some quick comments: * My usual reminder that new fields for existing audit records must be added to the end of the record. * If we are going to multiplex the labels on a single field (more on that below) I might suggest using "subj_lsms" instead of "lsms" so we leave ourself some wiggle room in the future. * Multiplexing on a single "subj" field is going to be difficult because picking the label delimiter is going to be a pain. For example, in the example above a comma is used, which at the very least is a valid part of a SELinux label and I suspect for Smack as well (I'm not sure about the other LSMs). I suspect the only way to parse out the component labels would be to have knowledge of the LSMs in use, as well as the policies loaded at the time the audit record was generated. This may be a faulty assumption, but assuming your tools will fall over if they see multiple "subj" fields, could we do something like the following (something between option #2 and #3): subj1_lsm=smack subj1=<smack_label> subj2_lsm=selinux subj2=<selinux_label> ...