Re: Preferred subj= with multiple LSMs

[Casey Schaufler <casey@schaufler-ca.com>]

On 7/15/2019 12:04 PM, Richard Guy Briggs wrote:
> On 2019-07-13 11:08, Steve Grubb wrote:
>> Hello,
>>
>> On Friday, July 12, 2019 12:33:55 PM EDT Casey Schaufler wrote:
>>> Which of these options would be preferred for audit records
>>> when there are multiple active security modules?
>> I'd like to start out with what is the underlying problem that results in 
>> this? For example, we have pam. It has multiple modules each having a vote. 
>> If a module votes no, then we need to know who voted no and maybe why. We 
>> normally do not need to know who voted yes.
>>
>> So, in a stacked situation, shouldn't each module make its own event, if 
>> required, just like pam? And then log the attributes as it knows them? Also, 
>> what model is being used? Does first module voting no end access voting? Or 
>> does each module get a vote even if one has already said no?
>>
>> Also, we try to keep LSM subsystems separated by record type numbers. So, 
>> apparmour and selinux events are entirely different record numbers and 
>> formats. Combining everything into one record is going to be problematic for 
>> reporting.
> I was wrestling with the options below and was uncomfortable with all of
> them because none of them was guaranteed not to break existing parsers.

I too, am uncomfortable regarding record parsing.

> Steve's answer is the obvious one, ideally allocating a seperate range
> to each LSM with each message type having its own well defined format.

It doesn't address the issue of success records, or records
generated outside the security modules.

>
>> -Steve
>>
>>> I'm not asking
>>> if we should do it, I'm asking which of these options I should
>>> implement when I do do it. I've prototyped #1 and #2. #4 is a
>>> minor variant of #1 that is either better for compatibility or
>>> worse, depending on how you want to look at it. I understand
>>> that each of these offer challenges. If I've missed something
>>> obvious, I'd be delighted to consider #5.
>>>
>>> Thank you.
>>>
>>> Option 1:
>>>
>>> 	subj=selinux='x:y:z:s:c',apparmor='a'
>>>
>>> Option 2:
>>>
>>> 	subj=x:y:z:s:c subj=a
>>>
>>> Option 3:
>>>
>>> 	lsms=selinux,apparmor subj=x:y:z:s:c subj=a
>>>
>>> Option 4:
>>>
>>> 	subjs=selinux='x:y:z:s:c',apparmor='a'
>>>
>>> Option 5:
>>>
>>> 	Something else.
> - RGB
>
> --
> Richard Guy Briggs <rgb@redhat.com>
> Sr. S/W Engineer, Kernel Security, Base Operating Systems
> Remote, Ottawa, Red Hat Canada
> IRC: rgb, SunRaycer
> Voice: +1.647.777.2635, Internal: (81) 32635