Re: Preferred subj= with multiple LSMs

On Tuesday, July 16, 2019 1:43:18 PM EDT Paul Moore wrote: > 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. But doing something like this will totally break all parsers. To be honest, I don't know if I'll ever see more than one labeled security system running at the same time. And this would be a big penalty to pay for the flexibility that someone, somewhere just might possibly do this.