netdev - Re: [PATCH ghak90 V6 00/10] audit: implement container identifier

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]

Date:   Mon, 22 Apr 2019 09:49:05 -0400
From:   Paul Moore <paul@...l-moore.com>
To:     Neil Horman <nhorman@...driver.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,
        sgrubb@...hat.com, omosnace@...hat.com, dhowells@...hat.com,
        simo@...hat.com, Eric Paris <eparis@...isplace.org>,
        Serge Hallyn <serge@...lyn.com>, ebiederm@...ssion.com
Subject: Re: [PATCH ghak90 V6 00/10] audit: implement container identifier

On Mon, Apr 22, 2019 at 7:38 AM Neil Horman <nhorman@...driver.com> wrote:
> On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote:
> > Implement kernel audit container identifier.
>
> I'm sorry, I've lost track of this, where have we landed on it? Are we good for
> inclusion?

I haven't finished going through this latest revision, but unless
Richard made any significant changes outside of the feedback from the
v5 patchset I'm guessing we are "close".

Based on discussions Richard and I had some time ago, I have always
envisioned the plan as being get the kernel patchset, tests, docs
ready (which Richard has been doing) and then run the actual
implemented API by the userland container folks, e.g. cri-o/lxc/etc.,
to make sure the actual implementation is sane from their perspective.
They've already seen the design, so I'm not expecting any real
surprises here, but sometimes opinions change when they have actual
code in front of them to play with and review.

Beyond that, while the cri-o/lxc/etc. folks are looking it over,
whatever additional testing we can do would be a big win.  I'm
thinking I'll pull it into a separate branch in the audit tree
(audit/working-container ?) and include that in my secnext kernels
that I build/test on a regular basis; this is also a handy way to keep
it based against the current audit/next branch.  If any changes are
needed Richard can either chose to base those changes on audit/next or
the separate audit container ID branch; that's up to him.  I've done
this with other big changes in other trees, e.g. SELinux, and it has
worked well to get some extra testing in and keep the patchset "merge
ready" while others outside the subsystem look things over.

-- 
paul moore
www.paul-moore.com