Re: Preferred subj= with multiple LSMs

On 7/15/2019 3:55 PM, Steve Grubb 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: >>>>> Hello, >>>>> >>>>> On Friday, July 12, 2019 12:33:55 PM EDT Casey Schaufler wrote: >>>>>> Which of these options would be preferred for audit records >>>>>> when there are multiple active security modules? >>>>> >>>>> I'd like to start out with what is the underlying problem that >>>>> results >>>>> in this? For example, we have pam. It has multiple modules each >>>>> having >>>>> a vote. If a module votes no, then we need to know who voted no and >>>>> maybe why. We normally do not need to know who voted yes. >>>>> >>>>> So, in a stacked situation, shouldn't each module make its own event, >>>>> if required, just like pam? And then log the attributes as it knows >>>>> them? Also, what model is being used? Does first module voting no end >>>>> access voting? Or does each module get a vote even if one has already >>>>> said no? >>>>> >>>>> Also, we try to keep LSM subsystems separated by record type numbers. >>>>> So, apparmour and selinux events are entirely different record >>>>> numbers >>>>> and formats. Combining everything into one record is going to be >>>>> problematic for reporting. >>>> >>>> I was wrestling with the options below and was uncomfortable with all >>>> of them because none of them was guaranteed not to break existing >>>> parsers. >>> >>> I too, am uncomfortable regarding record parsing. > > The record parsing for this is good as long as we are smart about it. We > have to be able to do searches on subject and object labels. By default, > ausearch uses strstr() to find a fragment of a label. That would still > work the same with multiple labels if done right. > >> If you can find me someone who is happy and comfortable with the >> current state of the audit record and/or formatting I would love to >> see them :) >> >>>> 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. 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 Unless there's an objection I will use this format with a slight modification. Smack allows commas in labels, so using a bare comma can lead to ambiguity. lsms=smack,apparmor subj="TS/Alpha,Beta","a" It's more code change than some of the other options, but if it has the best chance of working with user space I'm game.