Re: [PATCH v15 00/23] LSM: Module stacking for AppArmor

Steve Grubb
2020-03-06T17:15:20Z

On Tuesday, March 3, 2020 12:22:31 PM EST Casey Schaufler wrote:
> On 2/27/2020 9:29 AM, Casey Schaufler wrote:
> > On 2/21/2020 4:03 PM, Casey Schaufler wrote:
> >> Resending the audit related patches to the audit list,
> >> as there have been problems with the CC lists.
> >
> > There's an awful lot of interaction between the module stacking
> > and the audit sub-system. I have not gotten much feedback about
> > the audit changes recently, but I can't bring myself to think
> > this means there aren't any concerns. Before I start pushing for
> > the stacking to get pulled I would really appreciate either ACKs
> > or meaningful comments from the audit community. I can see that
> > there's a lot going on in the audit sub-system, and appreciate
> > that priorities may be elsewhere.
> >
> > Thank you.
>
> I have to start pushing on this series. If the audit community
> hasn't any additional feedback, I'll take it that what's here is
> acceptable and move my lobbying efforts elsewhere.

There is a limit in user space that may cause problems.

MAX_AUDIT_MESSAGE_LENGTH 8970 // PATH_MAX*2+CONTEXT_SIZE*2+11+256+1

This has been in place for years. This is designed to hand the AUDIT_PATH
record which can have PATH_MAX * 2 for name field, then it has 11 bytes set
aside for other fields, then 256 bytes to handle the largest possible SELinux
label. So, if we are agoing to stab other LSM's into the object identifier,
how big is it? Do you have a max size that everyone has to fit into?

Changing this constant in user space is not something that you set and are
done. Everything will need recompiling.

And one other question, no field names are changing because of this are they?
And if a distribution has only 1 LSM, will anyone notice a change in format?

-Steve