Re: Preferred subj= with multiple LSMs
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>
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