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 <[email protected]> > 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. Thank you. > > Since ausearch uses strstr(), this will still work. > >> I can toss out some suggestions but it would be nice to hear what Steve's >> tools would support with respect to LSM subject/object value formats. >> Steve, are these values interpreted at all by your tools, or are the opaque >> values? > subject label attributes are treat as strings. There is no attempt to > interpret portions of the strings to have any meaning. The main requirement > is that they have to be searchable. > > -Steve > > -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
