On 05/21/2018 01:21 PM, Steve Grubb wrote:
On Friday, May 18, 2018 12:34:24 PM EDT Mimi Zohar wrote:
> On Fri, 2018-05-18 at 11:56 -0400, Richard Guy Briggs wrote:
>> On 2018-05-18 10:39, Mimi Zohar wrote:
>>> On Fri, 2018-05-18 at 09:54 -0400, Stefan Berger wrote:
>>>> On 05/18/2018 08:53 AM, Mimi Zohar wrote:
>>> [..]
>>>
>>>>>>>> If so, which ones? We could probably refactor the
current
>>>>>>>> integrity_audit_message() and have ima_parse_rule() call
into it
>>>>>>>> to get
>>>>>>>> those fields as well. I suppose adding new fields to it
wouldn't
>>>>>>>> be
>>>>>>>> considered breaking user space?
>>>>>>> Changing the order of existing fields or inserting fields
could
>>>>>>> break
>>>>>>> stuff and is strongly discouraged without a good reason, but
>>>>>>> appending
>>>>>>> fields is usually the right way to add information.
>>>>>>>
>>>>>>> There are exceptions, and in this case, I'd pick the
"more
>>>>>>> standard" of
>>>>>>> the formats for AUDIT_INTEGRITY_RULE (ima_audit_measurement?)
and
>>>>>>> stick
>>>>>>> with that, abandoning the other format, renaming the less
>>>>>>> standard
>>>>>>> version of the record (ima_parse_rule?) and perhpas adopting
that
>>>>>>> abandonned format for the new record type while using
>>>>>>> current->audit_context.
>>>>> This sounds right, other than "type=INTEGRITY_RULE" (1805)
for
>>>>> ima_audit_measurement(). Could we rename type=1805 to be
>>>> So do we want to change both? I thought that what
>>>> ima_audit_measurement() produces looks ok but may not have a good
>>>> name
>>>> for the 'type'. Now in this case I would not want to 'break
user
>>>> space'.
>>>> The only change I was going to make was to what ima_parse_rule()
>>>> produces.
>>> The only change for now is separating the IMA policy rules from the
>>> IMA-audit messages.
>>>
>>> Richard, when the containerid is appended to the IMA-audit messages,
>>> would we make the audit type name change then?
>> No, go ahead and make the change now. I'm expecting that the
>> containerid record will just be another auxiliary record and should not
>> affect you folks.
> To summarize, we need to disambiguate the 1805, as both
> ima_parse_rule() and ima_audit_measurement() are using the same number
> with different formats. The main usage of 1805 that we are aware of
> is ima_audit_measurement(). Yet the "type=" name for
> ima_audit_measurement() should be INTEGRITY_IMA_AUDIT, not
> INTEGRITY_RULE.
>
> option 1: breaks both uses
> 1805 - INTEGRITY_IMA_AUDIT - ima_audit_measurement()
> 1806 - INTEGRITY_POLICY_RULE - ima_parse_rule()
>
> option 2: breaks the most common usage
> 1805 - INTEGRITY_RULE - ima_parse_rule()
> 1806 - INTEGRITY_IMA_AUDIT - ima_audit_measurement()
>
> option 3: leaves the most common usage with the wrong name, and breaks
> the other less common usage
> 1805 - INTEGRITY_RULE - ima_audit_measurement()
> 1806 - INTEGRITY_POLICY_RULE - ima_parse_rule()
>
> So option 3 is the best option?
From a user space perspective, I don't care as long the event is well formed
Are you saying this because of the tools you referred to that require
proper ordering and all fields need to be available?
(No unnecessary untrusted string logging) and we have the required
fields for
searching: pid, uid, auid, tty, session, subj, comm, exe, & res. And the
object is identifiable in the event.
There's at least one documented user that showed the existing format...
https://www.fireeye.com/blog/threat-research/2016/11/extending_linux_exec...