On 7/13/2020 6:19 PM, Paul Moore wrote:
> On Mon, Jul 13, 2020 at 9:08 PM Richard Guy Briggs <r...@redhat.com> wrote:
>> On 2020-07-13 20:11, Paul Moore wrote:
>>> On Mon, Jul 13, 2020 at 7:09 PM Casey Schaufler <ca...@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. 



--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Reply via email to