Re: Preferred subj= with multiple LSMs

[Steve Grubb <sgrubb@redhat.com>]

On Tuesday, July 16, 2019 12:00:05 PM EDT Casey Schaufler wrote:
> 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@schaufler-ca.com>
> > 
> > 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.

Quoting has a specific meaning in audit fields. So, we really shouldn't do 
that. We can simply pick another field delimiter. I really don't care which it 
is as long as its illegal for use in a label. For example, we use 

#define AUDIT_KEY_SEPARATOR 0x01

to separate key fields. We can pick almost anything. (exclamation mark, semi-
colon, hash, plus symbol, tilde, 0x02, whatever) But it will need to be 
documented and put into the API so that everyone is aware of the convention.

-Steve