Re: Preferred subj= with multiple LSMs

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

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