Preferred subj= with multiple LSMs

[Steve Grubb]

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

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