linux-kernel - Re: [PATCH ghak90 V6 05/10] audit: add contid support for signalling the audit daemon

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHC9VhRbxefdpTX5ct+1=uccv9b2GH+imDPPbB90RBWSjMcgbA@mail.gmail.com>
Date:   Tue, 9 Apr 2019 09:40:58 -0400
From:   Paul Moore <paul@...l-moore.com>
To:     Ondrej Mosnacek <omosnace@...hat.com>
Cc:     Richard Guy Briggs <rgb@...hat.com>,
        containers@...ts.linux-foundation.org, linux-api@...r.kernel.org,
        Linux-Audit Mailing List <linux-audit@...hat.com>,
        linux-fsdevel@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
        netdev@...r.kernel.org, netfilter-devel@...r.kernel.org,
        Steve Grubb <sgrubb@...hat.com>,
        David Howells <dhowells@...hat.com>,
        Simo Sorce <simo@...hat.com>,
        Eric Paris <eparis@...isplace.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        "Eric W . Biederman" <ebiederm@...ssion.com>, nhorman@...driver.com
Subject: Re: [PATCH ghak90 V6 05/10] audit: add contid support for signalling
 the audit daemon

On Tue, Apr 9, 2019 at 8:58 AM Ondrej Mosnacek <omosnace@...hat.com> wrote:
>
> On Tue, Apr 9, 2019 at 5:40 AM Richard Guy Briggs <rgb@...hat.com> wrote:
> > Add audit container identifier support to the action of signalling the
> > audit daemon.
> >
> > Since this would need to add an element to the audit_sig_info struct,
> > a new record type AUDIT_SIGNAL_INFO2 was created with a new
> > audit_sig_info2 struct.  Corresponding support is required in the
> > userspace code to reflect the new record request and reply type.
> > An older userspace won't break since it won't know to request this
> > record type.
> >
> > Signed-off-by: Richard Guy Briggs <rgb@...hat.com>
>
> This looks good to me.
>
> Reviewed-by: Ondrej Mosnacek <omosnace@...hat.com>
>
> Although I'm wondering if we shouldn't try to future-proof the
> AUDIT_SIGNAL_INFO2 format somehow, so that we don't need to add
> another AUDIT_SIGNAL_INFO3 when the need arises to add yet-another
> identifier to it... The simplest solution I can come up with is to add
> a "version" field at the beginning (set to 2 initially), then v<N>_len
> at the beginning of data for version <N>. But maybe this is too
> complicated for too little gain...

FWIW, I believe the long term solution to this is the fabled netlink
attribute approach that we haven't talked about in some time, but I
keep dreaming about (it has been mostly on the back burner becasue 1)
time and 2) didn't want to impact the audit container ID work).  While
I'm not opposed to trying to make things like this a bit more robust
by adding version fields and similar things, there are still so many
(so very many) problems with the audit kernel/userspace interface that
still need to be addressed.

-- 
paul moore
www.paul-moore.com