Re: Preferred subj= with multiple LSMs

On Tue, Jul 16, 2019 at 1:30 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; wrote: > On 7/16/2019 10:12 AM, Paul Moore wrote: >> 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> ... > If it's not a subj= field why use the indirection? > > subj_smack=<smack_label> subj_selinux=<selinux_label> > > would be easier. Good point, that looks reasonable to me.