Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp360850yba; Mon, 1 Apr 2019 07:51:21 -0700 (PDT) X-Google-Smtp-Source: APXvYqzFfgH5FR9hwUNWXNuiu0z/arEXNVa7Vb2udfUvuMk9EiCxuyfDfUoAUrkcxjWFymJFaGfl X-Received: by 2002:a63:2b41:: with SMTP id r62mr19757211pgr.403.1554130281002; Mon, 01 Apr 2019 07:51:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554130280; cv=none; d=google.com; s=arc-20160816; b=WTkLcXo6tWZJ4kVqzDMQxHKGR6c3uFSjjhJJBLgq3Rs8KkqEbDGFKdjgfexrq8diMW ajjmLsMHWpbi1Mps0/ZyE+blTk4E0CKTHJVdS+1lRH3zfQf4unHlTc6H33IXMiK4B3A0 rofq4sY+DwV2fLJTKA069VZ5Prt90l5zXm7MorhRwLYOKJB8TFjHzYerICUv41tkDNTT YSxtV2yroxgP3ATWjBxRBqyek/TczXIwT/vo19m92wQxr7Aghjm4lKKcdgzP0/njy3XE uoS7v0YPnzhAGZpPEpJeku2uRiEiur9amxgs6SlK8ZfIx6M9mBA0ntQsq5t9QyYh4HJ1 lYsg== 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 :in-reply-to:references:mime-version:dkim-signature; bh=C8yzsIqBBR4fXo9IZnoq+QYSJwLKkb1BMOVkzyPusUw=; b=n7cEi5hAAGmmIsu8TU/g05dehjqsd6i/XgaLfFUQbJF8kgtRq0qw5WTvTAN3I4j+eF iGoNc5ufkW1tm/Hzv0ZTC1jWSgOqqHbhS6i6YN+EAL0ezSIpBvSFl9LgpsboFGarPJwb z5Fdm9OG9JVQAhRQlvBbRaTrADexTwg4ZPrU+fMuY/F437+aLgB6UZs9+owqxOCnRmvR QxrHys9OFc34dDuocEbU0jlNdoLnZ6Cli5nIILWAeOCnO0U9HVwotTNZDMfIaMnfcgol JHTJxyrM73aR5SNwYOmuM0TXi6sWPcaXRUyr32l1tJ2mxPc5rB4iqHtmKKi1bgxJrPXY G0zg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=GxX7flHy; 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 q4si2476800pll.127.2019.04.01.07.51.05; Mon, 01 Apr 2019 07:51:20 -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=GxX7flHy; 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 S1728672AbfDAOuS (ORCPT + 99 others); Mon, 1 Apr 2019 10:50:18 -0400 Received: from mail-lf1-f67.google.com ([209.85.167.67]:35838 "EHLO mail-lf1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728563AbfDAOuR (ORCPT ); Mon, 1 Apr 2019 10:50:17 -0400 Received: by mail-lf1-f67.google.com with SMTP id u21so6527512lfu.2 for ; Mon, 01 Apr 2019 07:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C8yzsIqBBR4fXo9IZnoq+QYSJwLKkb1BMOVkzyPusUw=; b=GxX7flHyn5fSE/tWWrG4laQKKUZ+RDWqx1HGNTsuitAGp+ushI1Y0OB9VDcP9ORsgB d5l+3K2DYP56cwJaGHpH1pOMMnPb6g5elX99VYNcgBMq61HBw66ZCBl+/1Grt57AEM11 oR0+UwFH8yYq5QR809Os2jM7SCvugvA7zMJen1q6I5NeT+Uay7T82gPr7qiWCFxSzG1D Gi8hdShqogwNfwnl1UzUe6oV82+W02YbINddx1UrZIvB9Hgy4/9M2nOXP6dp0GLqg11V r2Aq/SzYe/Kbjuwkei0XqsHpseJZGpEoAL+OpoNVAmn7Q/SjoslCHu8St5EwzVLxHuUt Pm1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C8yzsIqBBR4fXo9IZnoq+QYSJwLKkb1BMOVkzyPusUw=; b=kc/gZrCLFn962TbDC4PKahx50anlYpif5/ylRJQeKITJdSI51V5Q0zyEG5/yxiBsVJ a6QjwxTrEr6Fqvj7OpSCkon4IdZrN/sHYOjnmf5+8VkQIl4RAdVaB4O5bDtpLzXdjkpT ZPCr7BzR7i+wDoHGdMq285xI1UtPeOOQKR143zgby8z2S2BPoXj4suVzoei50fSEhKff qRak+K8Rcf7cgNx2IUuDWr5UiLaMY1QtHlCRWhIo8V47SnM4smki3YTGvNNs9X8OYGoj pWsd2g3G4i/AQzhBTzCU4qyvKsBuBLOCrlsMRJiU4frWrCPYJFKd4C216QSSNAwEV7nP JAXQ== X-Gm-Message-State: APjAAAVkhoUsdZ8plKBHe+uv3cC4RrfnkaXXK7J7FgpGZ25KxvUh+zmD jkqaiyoPv43WU7nGHeTz2Z8cdkwbcPXW90SkvIud X-Received: by 2002:ac2:5205:: with SMTP id a5mr9071316lfl.102.1554130214951; Mon, 01 Apr 2019 07:50:14 -0700 (PDT) MIME-Version: 1.0 References: <27473c84a274c64871cfa8e3636deaf05603c978.1552665316.git.rgb@redhat.com> In-Reply-To: <27473c84a274c64871cfa8e3636deaf05603c978.1552665316.git.rgb@redhat.com> From: Paul Moore Date: Mon, 1 Apr 2019 10:50:03 -0400 Message-ID: Subject: Re: [PATCH ghak90 V5 09/10] audit: add support for containerid to network namespaces To: Richard Guy Briggs Cc: containers@lists.linux-foundation.org, linux-api@vger.kernel.org, Linux-Audit Mailing List , linux-fsdevel@vger.kernel.org, LKML , netdev@vger.kernel.org, netfilter-devel@vger.kernel.org, sgrubb@redhat.com, omosnace@redhat.com, dhowells@redhat.com, simo@redhat.com, Eric Paris , Serge Hallyn , ebiederm@xmission.com, nhorman@tuxdriver.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, Mar 15, 2019 at 2:35 PM 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 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 > > See: https://github.com/linux-audit/audit-kernel/issues/92 > See: https://github.com/linux-audit/audit-testsuite/issues/64 > See: https://github.com/linux-audit/audit-kernel/wiki/RFE-Audit-Container-ID > Signed-off-by: Richard Guy Briggs > --- > include/linux/audit.h | 19 ++++++++++++ > kernel/audit.c | 86 +++++++++++++++++++++++++++++++++++++++++++++++++-- > kernel/nsproxy.c | 4 +++ > 3 files changed, 106 insertions(+), 3 deletions(-) ... > diff --git a/kernel/audit.c b/kernel/audit.c > index cf448599ef34..7fa3194f5342 100644 > --- a/kernel/audit.c > +++ b/kernel/audit.c > @@ -72,6 +72,7 @@ > #include > #include > #include > +#include > > #include "audit.h" > > @@ -99,9 +100,13 @@ > /** > * struct audit_net - audit private network namespace data > * @sk: communication socket > + * @contid_list: audit container identifier list > + * @contid_list_lock audit container identifier list lock > */ > struct audit_net { > struct sock *sk; > + struct list_head contid_list; > + spinlock_t contid_list_lock; > }; > > /** > @@ -275,8 +280,11 @@ struct audit_task_info init_struct_audit = { > void audit_free(struct task_struct *tsk) > { > struct audit_task_info *info = tsk->audit; > + struct nsproxy *ns = tsk->nsproxy; > > audit_free_syscall(tsk); > + if (ns) > + audit_netns_contid_del(ns->net_ns, audit_get_contid(tsk)); > /* Freeing the audit_task_info struct must be performed after > * audit_log_exit() due to need for loginuid and sessionid. > */ > @@ -376,6 +384,73 @@ static struct sock *audit_get_sk(const struct net *net) > return aunet->sk; > } > > +void audit_netns_contid_add(struct net *net, u64 contid) > +{ > + struct audit_net *aunet = net_generic(net, audit_net_id); > + struct list_head *contid_list = &aunet->contid_list; > + struct audit_contid *cont; > + > + if (!audit_contid_valid(contid)) > + return; > + if (!aunet) > + return; We should move the contid_list assignment below this check, or decide that aunet is always going to valid (?) and get rid of this check completely. > + spin_lock(&aunet->contid_list_lock); > + if (!list_empty(contid_list)) We don't need the list_empty() check here do we? I think we can just call list_for_each_entry_rcu(), yes? > + list_for_each_entry_rcu(cont, contid_list, list) > + if (cont->id == contid) { > + refcount_inc(&cont->refcount); > + goto out; > + } > + cont = kmalloc(sizeof(struct audit_contid), GFP_ATOMIC); If you had to guess, what do you think is going to be more common: bumping the refcount of an existing entry in the list, or adding a new entry? I'm asking because I always get a little nervous when doing allocations while holding a spinlock. Yes, you are doing it with GFP_ATOMIC, but it still seems like something to try and avoid if this is going to approach 50%. However, if the new entry is rare then the extra work of always doing the allocation before taking the lock and then freeing it afterwards might be a bad tradeoff. My gut feeling says we might do about as many allocations as refcount bumps, but I could be thinking about this wrong. Moving the allocation outside the spinlock might also open the door to doing this as GFP_KERNEL, which is a good thing, but I haven't looked at the callers to see if that is possible (it may not be). That's an exercise left to the patch author (if he hasn't done that already). > + if (cont) { > + INIT_LIST_HEAD(&cont->list); Unless there is some guidance that INIT_LIST_HEAD() should be used regardless, you shouldn't need to call this here since list_add_rcu() will take care of any list.h related initialization. > + cont->id = contid; > + refcount_set(&cont->refcount, 1); > + list_add_rcu(&cont->list, contid_list); > + } > +out: > + spin_unlock(&aunet->contid_list_lock); > +} -- paul moore www.paul-moore.com