Preferred subj= with multiple LSMs

Paul Moore paul at paul-moore.com
Mon Jul 15 21:28:56 UTC 2019


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.

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; 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?

-- 
paul moore
www.paul-moore.com




More information about the Linux-audit mailing list