On Wed, May 29, 2019 at 10:07 AM Daniel Walsh [off-list ref] wrote:

On 5/29/19 9:17 AM, Paul Moore wrote:

quoted

On Wed, May 29, 2019 at 8:03 AM Daniel Walsh [off-list ref] wrote:

quoted

On 5/28/19 8:43 PM, Richard Guy Briggs wrote:

quoted

On 2019-05-28 19:00, Steve Grubb wrote:

quoted

On Tuesday, May 28, 2019 6:26:47 PM EDT Paul Moore wrote:

quoted

On Tue, May 28, 2019 at 5:54 PM Daniel Walsh [off-list ref] wrote:

quoted

On 4/22/19 9:49 AM, Paul Moore wrote:

quoted

On Mon, Apr 22, 2019 at 7:38 AM Neil Horman [off-list ref]

wrote:

quoted

quoted

quoted

quoted

On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote:

quoted

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.

Mrunal Patel (maintainer of CRI-O) and I have reviewed the API, and
believe this is something we can work on in the container runtimes team
to implement the container auditing code in CRI-O and Podman.

Thanks Dan.  If I pulled this into a branch and built you some test
kernels to play with, any idea how long it might take to get a proof
of concept working on the cri-o side?

We'd need to merge user space patches and let them use that instead of the
raw interface. I'm not going to merge user space until we are pretty sure the
patch is going into the kernel.

I have an f29 test rpm of the userspace bits if that helps for testing:
      http://people.redhat.com/~rbriggs/ghak90/git-1db7e21/

Here's what it contains (minus the last patch):
      https://github.com/linux-audit/audit-userspace/compare/master...rgbriggs:ghau40-containerid-filter.v7.0

quoted

-Steve

quoted

FWIW, I've also reached out to some of the LXC folks I know to get
their take on the API.  I think if we can get two different container
runtimes to give the API a thumbs-up then I think we are in good shape
with respect to the userspace interface.

I just finished looking over the last of the pending audit kernel
patches that were queued waiting for the merge window to open so this
is next on my list to look at.  I plan to start doing that
tonight/tomorrow, and as long as the changes between v5/v6 are not
that big, it shouldn't take too long.

- RGB

--
Richard Guy Briggs [off-list ref]
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635

Our current thoughts are to put the setting of the ID inside of conmon,
and then launching the OCI Runtime.  In a perfect world this would
happen in the OCI Runtime, but we have no controls over different OCI
Runtimes.

By putting it into conmon, then CRI-O and Podman will automatically get
the container id support.  After we have this we have to plumb it back
up through the contianer engines to be able to easily report the link
between the Container UUID and The Kernel Container Audit ID.

I'm glad you guys have a plan, that's encouraging, but sadly I have no
idea about the level of complexity/difficulty involved in modifying
the various container bits for a proof-of-concept?  Are we talking a
week or two?  A month?  More?

If we had the kernel and the libaudit api, it would involve a small
effort in conmon,  I would figure a few days for a POC.  Getting the
hole wiring into CRI-O and Podman, would be a little more effort.

That's great.  Stay tuned ...

-- 
paul moore
www.paul-moore.com