Re: Preferred subj= with multiple LSMs

On 7/16/2019 11:06 AM, Steve Grubb wrote: > 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. While I have never seen multiple-LSM plans from RedHat/IBM I have seen them from Ubuntu. This isn't hypothetical. I know that it's a hard problem, which is why we need to get it as right as possible.