Preferred subj= with multiple LSMs

[Casey Schaufler]

On 7/15/2019 3:55 PM, Steve Grubb wrote:
> On Monday, July 15, 2019 5:28:56 PM EDT Paul Moore wrote:
>> On Mon, Jul 15, 2019 at 3:37 PM Casey Schaufler <casey at schaufler-ca.com> 
> wrote:
>>> 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.
> The record parsing for this is good as long as we are smart about it. We have 
> to be able to do searches on subject and object labels. By default, ausearch 
> uses strstr() to find a fragment of a label. That would still work the same 
> with multiple labels if done right.
>
>
>> If you can find me someone who is happy and comfortable with the
>> current state of the audit record and/or formatting I would love to
>> see them :)
>>
>>>> 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.
>> Yes, exactly.  The individual LSM will presumably will continue to
>> generate their own audit records as they do today and I would imagine
>> that the subject and object fields could remain as they do today for
>> the LSM specific records.
>>
>> The trick is the other records which are not LSM specific but still
>> want to include subject and/or object information.  Unfortunately we
>> are stuck with some tough limitations given the current audit record
>> format and Steve's audit userspace tools; 
> Not really. We just need to approach the problem thinking about how to make 
> it work based on how things currently work. For example Casey had a list of 
> possible formats. Like this one:
>
> Option 3:
>         lsms=selinux,apparmor subj=x:y:z:s:c subj=a
>
> I'd suggest something almost like that. The first field could be a map to 
> decipher the labels. Then we could have a comma separated list of labels.
>
> lsms=selinux,apparmor subj=x:y:z:s:c,a

Unless there's an objection I will use this format with
a slight modification. Smack allows commas in labels, so
using a bare comma can lead to ambiguity.

lsms=smack,apparmor subj="TS/Alpha,Beta","a"

It's more code change than some of the other options,
but if it has the best chance of working with user space
I'm game.

Thank you.

>
> Since ausearch uses strstr(), this will still work. 
>
>> I can toss out some suggestions but it would be nice to hear what Steve's
>> tools would support with respect to LSM subject/object value formats. 
>> Steve, are these values interpreted at all by your tools, or are the opaque
>> values?
> subject label attributes are treat as strings. There is no attempt to 
> interpret portions of the strings to have any meaning. The main requirement 
> is that they have to be searchable.
>
> -Steve
>
>