Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1312478yba; Tue, 2 Apr 2019 06:41:05 -0700 (PDT) X-Google-Smtp-Source: APXvYqxHYRBIh407WEPUdmABKVDSkkeHEKeb/aPFDXI+yNc8N4NVmaxQ1+Kaj5I38bn21Qnm1A7z X-Received: by 2002:a63:1912:: with SMTP id z18mr68317048pgl.115.1554212465499; Tue, 02 Apr 2019 06:41:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554212465; cv=none; d=google.com; s=arc-20160816; b=rvrDm4nX23QsB8r5W7duUNwXlRNngdEh4SHBxrj9QmZAWzJrGWmM7jZ0nrWhZ4l+pi XMrSJroJFkf2IX1OhHS0tWTDBTIM2nMnDdYKlmF747ZVgS2km4AsagoM3+9MkR+uZ8DP 8QQD6CshRFA7Nlvsz8lRdWMhL0cSnq0oiRGvVafzlteyy5vS5YqjIm8x8THtyvvm+DlB Hmrbr5B/9mJmXbTdUhIiLwpXVpsPIs3jmW+Mn5sied3ULFmMtg8JtHpHcaKIWhy+MwLi HDPv8ubwO3ZE07RRvjXQGqbkG5PEofTsDamA1cYnD/LnWirMWXFFome+0oXM8DnmzZ1i X7lA== 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=d3JS4fLEKtdE2GQn7qN6jh6iLL/AcgQhWUFwsn/eE1Q=; b=JzQvRO0QxjBwACJE+lVFqhRy3xYkOzXzIZfVSwcsTx0IxzADdB/wnd/9Pxsqn1Ut77 D8swiSDnIVeMpa/hDGKof/85J2GyrqLi0bxn/EsR1cj+XsPzLG7ieTTiWdi2NVeZ82tk 1ONWpBhxZ++VOr0WEbztp9CzThP0mELlAA8s9XOrlR361lYteDK5XkLCjSsNKDAFs2FA vsQVJF/jwIHhhsTkOOmgJkyAZqcdKQmEXeva0JDO708UrusacYYa6QjXFKfIMdIvDmou GbGylqcvrIQhcP+nRL/AG9eJIsGzCySb21iPQiX0exv0GhCJfozOg6cBGWUW8e0X8BbV MBUA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b="pKc1/7zP"; 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 n13si1019582pgl.348.2019.04.02.06.40.50; Tue, 02 Apr 2019 06:41:05 -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="pKc1/7zP"; 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 S1731336AbfDBNcE (ORCPT + 99 others); Tue, 2 Apr 2019 09:32:04 -0400 Received: from mail-lj1-f196.google.com ([209.85.208.196]:38941 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731322AbfDBNcD (ORCPT ); Tue, 2 Apr 2019 09:32:03 -0400 Received: by mail-lj1-f196.google.com with SMTP id l7so11595154ljg.6 for ; Tue, 02 Apr 2019 06:32:01 -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=d3JS4fLEKtdE2GQn7qN6jh6iLL/AcgQhWUFwsn/eE1Q=; b=pKc1/7zPn2D6N+NI9MqaYbX0E6At37La/gcvjcT8KLuSszqHEd/zbWV/wfjpbtXoPA sYWRTjfbZAlP17dw04TPu69zXi3tpu+ouf1W3s7PvmEZxRmLrQB8XRZFHEfYC/pT2vdz uhpx8wnxw1CED4Ov9KcQzidsGN7QaoQs1TzIKOpa52ZcC2VK6Q+gzcajSr5yQrzPZi3K B1RvYlyzT47Ie4Lg+s9EAB5ys1dCCHkmCy/rh0OkpeUaccxw6QEAr5a7ItMshyKHj3hK CWp/DFfgIdCQgG73RybHqfffmCEU0ktleLNc2k6GiL6hLYzSlWZtTC4kwEzz3DnlV4TM rR1g== 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=d3JS4fLEKtdE2GQn7qN6jh6iLL/AcgQhWUFwsn/eE1Q=; b=Zzr2Hv5q4UZtEHRiYYN8B/wIX3CjWQ7S9cvGCSbeHU4uwwQ60OjaS1Xqi2SrOo4vjw MpYX+RQqofl55xj0yZUdHNU7WulXGe+KyreBTA4sx2gRAC57d630/KerXAyeWoaIZWfc LsI9Nz0jMeQAPpA+9yMVTUopEeF/7ZbT0Q2PBYSxywUSzvxdgUuONdJj3po9Saz1pkil wGBZS8YUnJ52MiHlN9nHObcaAe9fLZsDW5zh6Du0mp/DYae5Yc+jwkwNG5+MLgPDDS4Z /Jn34cOpx/k0JMAXUkgU2KHr6V0RQMXe9qPh8Rgt+ouCCByEvwaMqxN+UgCjROBBbF08 pUCQ== X-Gm-Message-State: APjAAAXzttAwWt41KPa+oyzjlcR76rPGMC7cleK5MVx73qiYGNC7l1N8 G/pKK00QfhBsanL9E8McH8gLFba1o+DDZcbCqfNH X-Received: by 2002:a2e:8508:: with SMTP id j8mr5227052lji.26.1554211920782; Tue, 02 Apr 2019 06:32:00 -0700 (PDT) MIME-Version: 1.0 References: <27473c84a274c64871cfa8e3636deaf05603c978.1552665316.git.rgb@redhat.com> <20190402113150.GA17593@hmswarspite.think-freely.org> In-Reply-To: <20190402113150.GA17593@hmswarspite.think-freely.org> From: Paul Moore Date: Tue, 2 Apr 2019 09:31:49 -0400 Message-ID: Subject: Re: [PATCH ghak90 V5 09/10] audit: add support for containerid to network namespaces To: Neil Horman Cc: Richard Guy Briggs , 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 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 Tue, Apr 2, 2019 at 7:32 AM Neil Horman wrote: > On Mon, Apr 01, 2019 at 10:50:03AM -0400, Paul Moore wrote: > > 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. > > > I'm not sure why that would be needed. Finding the net_id list is an operation > of a map relating net namespaces to lists, not contids to lists. We could do > it, sure, but since they're unrelated operations, I don't think we experience > any slowdowns from doing it this way. In the first line of the function, when aunet is declared, it is also assigned a value using net_generic(): struct audit_net *aunet = net_generic(net, audit_net_id); Later in the function there is check to see if aunet is NULL, yet on the second line of the function (before the NULL check), there is this line of code: struct list_head *contid_list = &aunet->contid_list; ... which could result in the dereference of a NULL pointer if aunet is NULL. My suggestion was either to move this assignment below the aunet-NULL check or decide that aunet was always going to be valid (e.g. non-NULL) and do away with the aunet-NULL check completely. Richard has since replied that the aunet-NULL check has been demonstrated to be necessary so the proper thing to do would be to move the assignment. I believe that is what Richard is planning on doing. > > > + 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. > > There is a corner case that needs it. list_add_rcu has a check that gets > called, __list_add_valid. Its a noop in the regular case, but if > CONFIG_DEBUG_LIST is defined, its a check to ensure that the next and prev > pointers getting passed in aren't set to detectable corrupt values. If we pass > in garbage, we can get transient false positives on that check, so we need to > set the list pointers to known good values before hand, either by using kzalloc, > or INIT_LIST_HEAD, as has been done here. Given that we expressly set every > field of this structure, I think this is the right approach, as it uses the list > macro to expressly set the list values to their proper state. Good to know, thanks. -- paul moore www.paul-moore.com