Re: [PATCH v15 00/23] LSM: Module stacking for AppArmor
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.