Re: [PATCH ghak122 v1] audit: store event sockaddr in case of no rules
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 <rgb(a)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?