On 3/6/2020 9:14 AM, Steve Grubb wrote: > 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.
Oh my. > 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? We already have a potential problem here. This implicitly limits the size of a label for all security modules. While we don't have a problem for any of the existing modules, it reasonable to assume that some module some day may want more than that. We have a dearth of documentation on what security modules can and can't do, including limits like this. > Changing this constant in user space is not something that you set and are > done. Everything will need recompiling. Unfortunate, but hardly a surprise. I can see that having a MAX_AUDIT_MESSAGE_LENGTH is going to require some finagling regardless of what value it has. > And one other question, no field names are changing because of this are they? No field names change. subj= and obj= remain as they are. subj_selinux=, obj_smack= and the like are added. > And if a distribution has only 1 LSM, will anyone notice a change in format? No. Explicit steps are taken to ensure that the new fields are produced only if there's more than one active security module. > -Steve Thanks for the response. I'll be making more comments based on Paul's feedback. -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
