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

Steve Grubb sgrubb at redhat.com
Fri Mar 6 17:14:59 UTC 2020


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





More information about the Linux-audit mailing list