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

[Casey Schaufler]

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.