linux-audit.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: Paul Moore <paul@paul-moore.com>, Richard Guy Briggs <rgb@redhat.com>
Cc: Eric Paris <eparis@parisplace.org>,
	Linux-Audit Mailing List <linux-audit@redhat.com>
Subject: Re: [PATCH ghak122 v1] audit: store event sockaddr in case of no rules
Date: Mon, 13 Jul 2020 19:37:25 -0700	[thread overview]
Message-ID: <a882800f-9677-7bcb-9833-1fd8f374f6ff@schaufler-ca.com> (raw)
In-Reply-To: <CAHC9VhQB6m_TtsQEnpanfaAd_mH3wp4jg-UByTjvdyUinw5Y9g@mail.gmail.com>

On 7/13/2020 6:19 PM, Paul Moore wrote:
> On Mon, Jul 13, 2020 at 9:08 PM Richard Guy Briggs <rgb@redhat.com> wrote:
>> On 2020-07-13 20:11, Paul Moore wrote:
>>> On Mon, Jul 13, 2020 at 7:09 PM Casey Schaufler <casey@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	other threads:[~2020-07-14  2:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-03 17:17 [PATCH ghak122 v1] audit: store event sockaddr in case of no rules Richard Guy Briggs
2020-07-08 22:49 ` Paul Moore
2020-07-13 17:40   ` Richard Guy Briggs
2020-07-13 17:55     ` Casey Schaufler
2020-07-13 20:02       ` Richard Guy Briggs
2020-07-13 23:08         ` Casey Schaufler
2020-07-14  0:11           ` Paul Moore
2020-07-14  0:28             ` Casey Schaufler
2020-07-14  0:47               ` Paul Moore
2020-07-14  1:08             ` Richard Guy Briggs
2020-07-14  1:19               ` Paul Moore
2020-07-14  2:37                 ` Casey Schaufler [this message]
2020-07-13 22:30     ` Paul Moore
2020-07-13 22:37       ` Steve Grubb

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a882800f-9677-7bcb-9833-1fd8f374f6ff@schaufler-ca.com \
    --to=casey@schaufler-ca.com \
    --cc=eparis@parisplace.org \
    --cc=linux-audit@redhat.com \
    --cc=paul@paul-moore.com \
    --cc=rgb@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).