On 7/13/2020 1:02 PM, Richard Guy Briggs wrote:
> On 2020-07-13 10:55, Casey Schaufler wrote:
>> On 7/13/2020 10:40 AM, Richard Guy Briggs wrote:
>>> On 2020-07-08 18:49, Paul Moore wrote:
>>>> On Fri, Jul 3, 2020 at 1:18 PM Richard Guy Briggs <r...@redhat.com> wrote:
>>>>> When there are no rules present, the event SOCKADDR record is not
>>>>> generated due to audit_dummy_context() generated at syscall entry from
>>>>> audit_n_rules. Store this information if there is a context present to
>>>>> store it so that mandatory events are more complete (startup, LSMs...).
>> I don't know for sure, but this looks a lot like the issues
>> I have had to address for LSM stacking in
>>
>> [PATCH v18 20/23] Audit: Add new record for multiple process LSM attributes
>>
>> I don't know if the approach I took will help here, or be
>> acceptable at all for that matter. But it might be worth taking
>> a look.
> The first thing I notice is audit_stamp_context() looks pretty similar
> to audit_alloc_local() in
Sure does, doesn't it.
> [PATCH ghak90 V9 07/13] audit: add support for non-syscall auxiliary records
>
> which creates a local context for limited use by the primary record and
> local auxiliary records (contid) and is immediately tossed after those
> records. One use case is network namespace events that are not (yet)
> tied to any user context ("[PATCH ghak90 V9 10/13] audit: add support
> for containerid to network namespaces"). The other is for user records
> that don't need to be tied to the userspace caller ("[PATCH ghak90 V9
> 08/13] audit: add containerid support for user records").
>
> How does this tie in with this situation?
In the case where subject LSM context information is being provided
and there is more than one LSM active that uses subject contexts
(e.g. AppArmor and SELinux, or AppArmor and Smack) the audit event can't
use the old "subj=xyz" field. Instead, the field will be "subj=?" and
a new record added to the event that contains all the subject contexts.
As is true in the cases you have here, not all the events involved are
syscall events.
> I would ideally like to
> retroactively capture the sockaddr information in the audit context
> struct (to avoid the overhead of always capturing sockaddr) to trigger a
> syscall record on exit along with a sockaddr record once a manadatory
> record has been triggered (such as audit or netfilter config, LSM event,
> etc...), depending only on audit_enabled. There could be other
> substructures of audit context that would need filling out after it is
> determined that an audit event has happenned and information needs to be
> collected to support its reporting.
I'm not sure that I completely understand all that you're looking at,
but it does appear that I could switch to using your audit_alloc_local().
Do you think that has achieved its final form?
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
