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 -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
