Re: Preferred subj= with multiple LSMs

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.