Re: Preferred subj= with multiple LSMs

On Tue, Jul 16, 2019 at 2:41 PM Casey Schaufler <casey(a)schaufler-ca.com&gt;

> 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;

> >>>>> 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. Agreed. While I'm not going to be on a specific Linux release, I do believe that at some point in the future the LSM stacking work is going to land in Linus' tree. Perhaps you'll never see it Steve, but we need to prepare the code to handle it when it happens.

For my own sanity, here is a quick summary of the constraints as I currently see them, please feel free to add/disagree: * We can't have multiple "subj" fields in a single audit record. * The different LSMs all have different label formats and allowed characters. Further, a given label format may not be unique for a given LSM; for example, Smack could be configured with a subset of SELinux labels. * Steve's audit tools appear to require a "subj" and "obj" fields for LSM information or else they break into tiny little pieces.

What if we preserved the existing subj/obj fields in the case where there is only one "major" LSM (SELinux, Smack, AppArmor, etc.): subj=<lsm_label> ... and in the case of multiple major LSMs we set the subj value to "?" and introduce new subj_X fields (as necessary) as discussed above: subj=? subj_smack=<smack_label> subj_selinux=<selinux_label> ... ... I believe that Steve's old/existing userspace tools would simply report "?"/unknown LSM credentials where new multi-LSM tools could report the multiple different labels.

While this may not be perfect, it avoids having to multiplex the different labels into a single field (which is a big win IMHO) with the only issue being that multi-LSM solutions will need an updated audit toolset to see the new labels (which seems like a reasonable requirement).