Received: by 10.192.165.148 with SMTP id m20csp676269imm; Fri, 20 Apr 2018 13:28:52 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+sLkKafWjsUTFqOj+7hiEG46KZiMNQfL2nUbytbwHGriNIrJ7QiQnLG7aoTHBWorse4MBj X-Received: by 2002:a17:902:3381:: with SMTP id b1-v6mr11536320plc.248.1524256132878; Fri, 20 Apr 2018 13:28:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524256132; cv=none; d=google.com; s=arc-20160816; b=dml1DsPfKXnYvEs0p6N4776WvZ+gArLRgIxJMPAEEznbV8bLLQhp/RCBML+DYTuzhx /P96wdHlM98at65TJS8erogXZF2Umc8WOgLd4K5hxKpnL0GQUitNAPmFtZxSBWyYuNqv /oxrL0ChM82k47qH+l7rrPeHu5Z68n+S88PZVAsHGoD1PUyCv/hybz3HgVHAELuq3TFo T6x73TnRwKyU9RUsOWjhE/cs0U/tGJBUHZjsi2BaShh4R/p057rR0zwV+dHWIW5W2MvA fLdDGiCmGRfP+IJnZ/ZXZnJDluUofEj/gi3/fAT7RBuDJiq9a7Pwd7dXgM8qmzAGEOdO fnnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=7Oxe6e7HdAQ7QpitAvG879uxrtnL5kymvGmHqa37GCw=; b=pcZfl8LiW/Ccc/az6U2sudy/H5i+OTE8kGJTMc54y5tjSsbVAcvqevRgkUflqIzPyO BVCk0HTPH0tg0TAnXG62asO9GlW8vs4laDOIpm9N8XyrVv4GsYn5TbzJyKHMMZSrZHs3 2rala+ZAD+2O23oBGWWcD8mN7jqRACHoidwJrKYroJqW+DclXcDlpJFTNTsYPMRZrYr8 MgMMZT7dDw+n7St1hUk5wUS+oQYsC2zAqMnJ3f+3kuAVcOdGOdSNv4Z6WjqBWgQRxMAx Oe11OXJgBDDKiv2EHhf05DDYQx4X72dEtGfzPjpNAkjjxH5/WRymQ2xrXc+C7LHcW33A Lokg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=iTUwY8Ug; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t25si5786523pfh.101.2018.04.20.13.28.16; Fri, 20 Apr 2018 13:28:52 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=iTUwY8Ug; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752214AbeDTUWY (ORCPT + 99 others); Fri, 20 Apr 2018 16:22:24 -0400 Received: from mail-lf0-f66.google.com ([209.85.215.66]:39000 "EHLO mail-lf0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751375AbeDTUWV (ORCPT ); Fri, 20 Apr 2018 16:22:21 -0400 Received: by mail-lf0-f66.google.com with SMTP id p142-v6so6820867lfd.6 for ; Fri, 20 Apr 2018 13:22:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7Oxe6e7HdAQ7QpitAvG879uxrtnL5kymvGmHqa37GCw=; b=iTUwY8UgDEnORGGgOBIeo7bpF9R3Ag/QN6AAfUBJY8xj9erSbClUJqN+blM56mIQua U9Ufx7YK6frL/YsCLERw3B6E7Hwf1TrFsackf1ZJNyC82bD16NuEN0uz0uYQkwg4kFwL GQYfQnjpJyGr9UBpldn6PTHiLN4RFeCbCXkBnK9MHqMuReSUHH/+bHUeAVf7j5VRw+vX QhhHWF9OBoF3Uvyn6SufBGFGKjHCEec7zj5dWDHXn5BGfuNiiM7GGwsPPpwX/maHM2gi Lg+2+A7FIetWtGDtdGJT7ZSlnqaq1OY8cZb8s9T1JIjZDs2AYLNRqEP3C9/+MKBM7Lyz rAQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7Oxe6e7HdAQ7QpitAvG879uxrtnL5kymvGmHqa37GCw=; b=pAkEO9RS6Z4CrM5toloUGXNeqGy4lQJ+rbgfboOcKylmZB3ZUtoKEPU43uwydF746H hS0OR5JvPjrGVmFquSw2MVR2ElzKs6JqV0pcUin99t8YqcdWIemIVcLdmL864vS2diiD mounCOBmN5hVc0ieI2M/4mZSl4N1whYC+4QqoXycMTdjytKYczDn+dijzJbewep/iTqO MJYS/+177x0F0lf+FGiL4Bk8mV1g9jpty02NkbdkM+mEoexv3PSCSvjE3b55ogZpROeZ OJ2TrY1ANgk9BDeImq11n2ghpBiNjscxkhGK+tTIy3NlpOjCzEU6glGDSIvXBeRwmPgN d6+Q== X-Gm-Message-State: ALQs6tBTqG6Hf4+qlooVD/kO4dJ7pHWrAomECtg8Rkk+UO+jooWIoPgN 7fJ7Mlhk2qshiEWAcDBKcYCLAMLCnBUhuvba4SGE X-Received: by 2002:a19:8e8e:: with SMTP id a14-v6mr3746154lfl.145.1524255739405; Fri, 20 Apr 2018 13:22:19 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:a5c3:0:0:0:0:0 with HTTP; Fri, 20 Apr 2018 13:22:18 -0700 (PDT) X-Originating-IP: [108.20.156.165] In-Reply-To: <20180420200226.7tyxzuovdbgclw3m@madcap2.tricolour.ca> References: <11b43a498e768a14764594c808a96b34d52be0af.1521179281.git.rgb@redhat.com> <20180420200226.7tyxzuovdbgclw3m@madcap2.tricolour.ca> From: Paul Moore Date: Fri, 20 Apr 2018 16:22:18 -0400 Message-ID: Subject: Re: [RFC PATCH ghak32 V2 11/13] audit: add support for containerid to network namespaces To: Richard Guy Briggs Cc: cgroups@vger.kernel.org, containers@lists.linux-foundation.org, linux-api@vger.kernel.org, Linux-Audit Mailing List , linux-fsdevel@vger.kernel.org, LKML , netdev@vger.kernel.org, ebiederm@xmission.com, luto@kernel.org, jlayton@redhat.com, carlos@redhat.com, dhowells@redhat.com, viro@zeniv.linux.org.uk, simo@redhat.com, Eric Paris , serge@hallyn.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 20, 2018 at 4:02 PM, Richard Guy Briggs wrote: > On 2018-04-18 21:46, Paul Moore wrote: >> On Fri, Mar 16, 2018 at 5:00 AM, Richard Guy Briggs wrote: >> > 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 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 container identifiiers. >> > >> > Add/increment the container identifier on: >> > - initial setting of the container id via /proc >> > - clone/fork call that inherits a container identifier >> > - unshare call that inherits a container identifier >> > - setns call that inherits a container identifier >> > Delete/decrement the container identifier on: >> > - an inherited container id dropped when child set >> > - process exit >> > - unshare call that drops a net namespace >> > - setns call that drops a net namespace >> > >> > See: https://github.com/linux-audit/audit-kernel/issues/32 >> > See: https://github.com/linux-audit/audit-testsuite/issues/64 >> > Signed-off-by: Richard Guy Briggs >> > --- >> > include/linux/audit.h | 7 +++++++ >> > include/net/net_namespace.h | 12 ++++++++++++ >> > kernel/auditsc.c | 9 ++++++--- >> > kernel/nsproxy.c | 6 ++++++ >> > net/core/net_namespace.c | 45 +++++++++++++++++++++++++++++++++++++++++++++ >> > 5 files changed, 76 insertions(+), 3 deletions(-) ... >> > diff --git a/kernel/nsproxy.c b/kernel/nsproxy.c >> > index f6c5d33..d9f1090 100644 >> > --- a/kernel/nsproxy.c >> > +++ b/kernel/nsproxy.c >> > @@ -140,6 +140,7 @@ int copy_namespaces(unsigned long flags, struct task_struct *tsk) >> > struct nsproxy *old_ns = tsk->nsproxy; >> > struct user_namespace *user_ns = task_cred_xxx(tsk, user_ns); >> > struct nsproxy *new_ns; >> > + u64 containerid = audit_get_containerid(tsk); >> > >> > if (likely(!(flags & (CLONE_NEWNS | CLONE_NEWUTS | CLONE_NEWIPC | >> > CLONE_NEWPID | CLONE_NEWNET | >> > @@ -167,6 +168,7 @@ int copy_namespaces(unsigned long flags, struct task_struct *tsk) >> > return PTR_ERR(new_ns); >> > >> > tsk->nsproxy = new_ns; >> > + net_add_audit_containerid(new_ns->net_ns, containerid); >> > return 0; >> > } >> >> Hopefully we can handle this in audit_net_init(), we just need to >> figure out where we can get the correct task_struct for the audit >> container ID (some backpointer in the net struct?). > > I don't follow. This needs to happen on every task startup. > audit_net_init() is only called when a new network namespace starts up. Yep, sorry, my mistake. I must have confused myself when I was looking at the code. I'm thinking out loud here, bear with me ... Assuming we move the netns/audit-container-ID tracking to audit_net, and considering we already have an audit hook in copy_process() (it calls audit_alloc()), would this be better handled by the copy_process() hook? This ignores naming, audit_alloc() reuse, etc.; those can be easily fixed. I'm just thinking of ways to limit our impact on the core kernel and leverage our existing interaction points. -- paul moore www.paul-moore.com