[PATCH ghak122 v1] audit: store event sockaddr in case of no rules

[Casey Schaufler]

On 7/13/2020 6:19 PM, Paul Moore wrote:
> On Mon, Jul 13, 2020 at 9:08 PM Richard Guy Briggs <rgb at redhat.com> wrote:
>> On 2020-07-13 20:11, Paul Moore wrote:
>>> On Mon, Jul 13, 2020 at 7:09 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
>>>> ... but it does appear that I could switch to using your audit_alloc_local().
>>> In my opinion, linking the audit container ID and LSM stacking
>>> patchsets would seem like a very big mistake, especially since the
>>> consolidation you are describing could be done after the fact without
>>> any disruption to the kernel/userspace interface.  I would strongly
>>> encourage both patchsets to remain self-contained if at all possible
>>> so as to not jeopardize each other.
>> I see no need to link them.  The audit_alloc_local() patch could stand
>> on its own to be used by either patchset and doesn't need to be included
>> in the contid patchset.  There is no mention of contid in it.  Patches 8
>> and 11 depend on it so as long as it is already upstream that's fine.
> Let me be clear, please don't do this.  I really dislike that we need
> audit_alloc_local(), but we do because computers are awful things and
> audit is perhaps even more awful.

Computers *are* awful, and getting awfuller. Audit is awful beyond
comprehension because the people who wrote the audit section of the
Orange Book didn't talk to the people who wrote the access control section,
and neither talked with anyone who hadn't worked on MULTICS. I wrote three
UNIX audit systems, helped out on several others and derailed the POSIX
effort completely. I have tried to avoid understanding Linux audit so far,
but have finally gotten to the point where I have to know something about
it. It's far from the worst I've seen. There are aspects I find peculiar,
but I have my (rather firm and old fashioned) notions.

> Someday I'll make my peace with audit_alloc_local(), and/or it will
> become something more useful through consolidation, but now is not the
> time to push on this issue considering where the audit container ID
> patchset is at.

And now I'm coming in with a similar notion for stacking. Thanks for
your forbearance. We know there's lots on your plate, and that we're
coming at you from all directions.