On Tue, Feb 4, 2020 at 6:43 PM Richard Guy Briggs <rgb@xxxxxxxxxx> wrote: > On 2020-01-22 16:28, Paul Moore wrote: > > On Tue, Dec 31, 2019 at 2:51 PM Richard Guy Briggs <rgb@xxxxxxxxxx> wrote: > > > > > > This also adds support to qualify NETFILTER_PKT records. > > > > > > Audit events could happen in a network namespace outside of a task > > > context due to packets received from the net that trigger an auditing > > > rule prior to being associated with a running task. The network > > > namespace could be in use by multiple containers by association to the > > > tasks in that network namespace. We still want a way to attribute > > > these events to any potential containers. Keep a list per network > > > namespace to track these audit container identifiiers. > > > > > > Add/increment the audit container identifier on: > > > - initial setting of the audit container identifier via /proc > > > - clone/fork call that inherits an audit container identifier > > > - unshare call that inherits an audit container identifier > > > - setns call that inherits an audit container identifier > > > Delete/decrement the audit container identifier on: > > > - an inherited audit container identifier dropped when child set > > > - process exit > > > - unshare call that drops a net namespace > > > - setns call that drops a net namespace > > > > > > Add audit container identifier auxiliary record(s) to NETFILTER_PKT > > > event standalone records. Iterate through all potential audit container > > > identifiers associated with a network namespace. > > > > > > Please see the github audit kernel issue for contid net support: > > > https://github.com/linux-audit/audit-kernel/issues/92 > > > Please see the github audit testsuiite issue for the test case: > > > https://github.com/linux-audit/audit-testsuite/issues/64 > > > Please see the github audit wiki for the feature overview: > > > https://github.com/linux-audit/audit-kernel/wiki/RFE-Audit-Container-ID > > > Signed-off-by: Richard Guy Briggs <rgb@xxxxxxxxxx> > > > Acked-by: Neil Horman <nhorman@xxxxxxxxxxxxx> > > > Reviewed-by: Ondrej Mosnacek <omosnace@xxxxxxxxxx> > > > --- > > > include/linux/audit.h | 24 +++++++++ > > > kernel/audit.c | 132 ++++++++++++++++++++++++++++++++++++++++++++++- > > > kernel/nsproxy.c | 4 ++ > > > net/netfilter/nft_log.c | 11 +++- > > > net/netfilter/xt_AUDIT.c | 11 +++- > > > 5 files changed, 176 insertions(+), 6 deletions(-) > > > > ... > > > > > diff --git a/include/linux/audit.h b/include/linux/audit.h > > > index 5531d37a4226..ed8d5b74758d 100644 > > > --- a/include/linux/audit.h > > > +++ b/include/linux/audit.h > > > @@ -12,6 +12,7 @@ > > > #include <linux/sched.h> > > > #include <linux/ptrace.h> > > > #include <uapi/linux/audit.h> > > > +#include <linux/refcount.h> > > > > > > #define AUDIT_INO_UNSET ((unsigned long)-1) > > > #define AUDIT_DEV_UNSET ((dev_t)-1) > > > @@ -121,6 +122,13 @@ struct audit_task_info { > > > > > > extern struct audit_task_info init_struct_audit; > > > > > > +struct audit_contobj_netns { > > > + struct list_head list; > > > + u64 id; > > > > Since we now track audit container IDs in their own structure, why not > > link directly to the audit container ID object (and bump the > > refcount)? > > Ok, I've done this but at first I had doubts about the complexity. Yes, it will be more complex, but it should be much safer. -- paul moore www.paul-moore.com
