The need for nested container support is the `Enemy of the good`. This
idea has been being worked on for years and has always been blocked by
this seldom used feature.
We are working on a project right this summer to allow us to use the
audit system to track the syscalls used by a container and then generate
a seccomp.json file to lock down the container in the future. Think of
it as Audit2allow for seccomp rules on a container. The problem is,
other then PID1 inside of the container, it is real difficult to follow
the other processes inside of the container without a containerid.
Is there a chance we could get a single ID for a container for now, and
then enhance the feature in the future for nested ContainerIDs.
I fear that this will block the container id for years.
On 6/3/19 6:01 PM, Paul Moore wrote:
On Fri, May 31, 2019 at 1:54 PM Richard Guy Briggs
<rgb(a)redhat.com> wrote:
> Remove the BUG() call since we will never have an invalid op value as
> audit_data_to_entry()/audit_to_op() ensure that the op value is a a
> known good value.
>
> Signed-off-by: Richard Guy Briggs <rgb(a)redhat.com>
> ---
> kernel/auditfilter.c | 1 -
> 1 file changed, 1 deletion(-)
Thanks for sending this out. However, in light of the discussion in
the patchset's cover letter it looks like we need to better support
nested container orchestrators which is likely going to require some
non-trivial changes to the kernel/userspace API. Because of this I'm
going to hold off pulling these patches into a "working" branch,
hopefully the next revision of these patches will solve the nested
orchestrator issue enough that we can continue to move forward with
testing.
> diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
> index 407b5bb3b4c6..385a114a1254 100644
> --- a/kernel/auditfilter.c
> +++ b/kernel/auditfilter.c
> @@ -1244,7 +1244,6 @@ int audit_comparator64(u64 left, u32 op, u64 right)
> case Audit_bittest:
> return ((left & right) == right);
> default:
> - BUG();
> return 0;
> }
> }
> --
> 1.8.3.1
>