| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20200721220548.oy5iwquoohevlgbi@madcap2.tricolour.ca>
Date: Tue, 21 Jul 2020 18:05:48 -0400
From: Richard Guy Briggs <rgb@...hat.com>
To: Paul Moore <paul@...l-moore.com>
Cc: containers@...ts.linux-foundation.org, linux-api@...r.kernel.org,
Linux-Audit Mailing List <linux-audit@...hat.com>,
linux-fsdevel@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
netdev@...r.kernel.org, netfilter-devel@...r.kernel.org,
sgrubb@...hat.com, Ondrej Mosnacek <omosnace@...hat.com>,
dhowells@...hat.com, simo@...hat.com,
Eric Paris <eparis@...isplace.org>,
Serge Hallyn <serge@...lyn.com>, ebiederm@...ssion.com,
nhorman@...driver.com, Dan Walsh <dwalsh@...hat.com>,
mpatel@...hat.com
Subject: Re: [PATCH ghak90 V9 10/13] audit: add support for containerid to
network namespaces
On 2020-07-05 11:11, Paul Moore wrote:
> On Sat, Jun 27, 2020 at 9:23 AM Richard Guy Briggs <rgb@...hat.com> 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@...hat.com>
> > Acked-by: Neil Horman <nhorman@...driver.com>
> > Reviewed-by: Ondrej Mosnacek <omosnace@...hat.com>
> > ---
> > include/linux/audit.h | 20 ++++++
> > kernel/audit.c | 156 ++++++++++++++++++++++++++++++++++++++++++++++-
> > kernel/nsproxy.c | 4 ++
> > net/netfilter/nft_log.c | 11 +++-
> > net/netfilter/xt_AUDIT.c | 11 +++-
> > 5 files changed, 195 insertions(+), 7 deletions(-)
> >
> > diff --git a/include/linux/audit.h b/include/linux/audit.h
> > index c4a755ae0d61..304fbb7c3c5b 100644
> > --- a/include/linux/audit.h
> > +++ b/include/linux/audit.h
> > @@ -128,6 +128,13 @@ struct audit_task_info {
> >
> > extern struct audit_task_info init_struct_audit;
> >
> > +struct audit_contobj_netns {
> > + struct list_head list;
> > + struct audit_contobj *obj;
> > + int count;
>
> This seems like it might be a good candidate for refcount_t, yes?
I considered this before when converting the struct audit_contobj to
refcount_t, but decided against it since any updates are in the context
of a list traversal where it could be added to the list and so the
spinlock is already held anyways.
Is there a more efficent or elegant way of doing the locking around the
two list traversals below (_add and _del)?
I wonder about converting the count to refcount_t and only holding the
spinlock for the list_add_rcu() in the _add case. And for the _del case
holding the spinlock only for the list_del_rcu().
These are the only two locations items are added or deleted from the
lists.
Somewhat related to this is does the list order matter? Items are
currently added at the end of the list which likely makes locking
simpler, though the start of the list is a simple change. However,
unless we understand the profile of read use of these lists for
reporting contid use in audit_log_netns_contid_list() I don't think
order matters significantly. It could be that reporting of a contid
goes down in frequency over the lifetime of a contid that inserting them
at the beginning of the list would be best. This is not a visible
implementation detail so later optimization should pose no problem.
> > + struct rcu_head rcu;
> > +};
>
> ...
>
> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index 997c34178ee8..a862721dfd9b 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -437,6 +452,136 @@ static struct sock *audit_get_sk(const struct net *net)
> > return aunet->sk;
> > }
> >
> > +void audit_netns_contid_add(struct net *net, struct audit_contobj *cont)
> > +{
> > + struct audit_net *aunet;
> > + struct list_head *contobj_list;
> > + struct audit_contobj_netns *contns;
> > +
> > + if (!net)
> > + return;
> > + if (!cont)
> > + return;
> > + aunet = net_generic(net, audit_net_id);
> > + if (!aunet)
> > + return;
> > + contobj_list = &aunet->contobj_list;
> > + rcu_read_lock();
> > + spin_lock(&aunet->contobj_list_lock);
> > + list_for_each_entry_rcu(contns, contobj_list, list)
> > + if (contns->obj == cont) {
> > + contns->count++;
> > + goto out;
> > + }
> > + contns = kmalloc(sizeof(*contns), GFP_ATOMIC);
> > + if (contns) {
> > + INIT_LIST_HEAD(&contns->list);
> > + contns->obj = cont;
> > + contns->count = 1;
> > + list_add_rcu(&contns->list, contobj_list);
> > + }
> > +out:
> > + spin_unlock(&aunet->contobj_list_lock);
> > + rcu_read_unlock();
> > +}
> > +
> > +void audit_netns_contid_del(struct net *net, struct audit_contobj *cont)
> > +{
> > + struct audit_net *aunet;
> > + struct list_head *contobj_list;
> > + struct audit_contobj_netns *contns = NULL;
> > +
> > + if (!net)
> > + return;
> > + if (!cont)
> > + return;
> > + aunet = net_generic(net, audit_net_id);
> > + if (!aunet)
> > + return;
> > + contobj_list = &aunet->contobj_list;
> > + rcu_read_lock();
> > + spin_lock(&aunet->contobj_list_lock);
> > + list_for_each_entry_rcu(contns, contobj_list, list)
> > + if (contns->obj == cont) {
> > + contns->count--;
> > + if (contns->count < 1) {
>
> One could simplify this with "(--countns->count) < 1", although if it
> is changed to a refcount_t (which seems like a smart thing), the
> normal decrement/test would be the best choice.
Agreed.
> > + list_del_rcu(&contns->list);
> > + kfree_rcu(contns, rcu);
> > + }
> > + break;
> > + }
> > + spin_unlock(&aunet->contobj_list_lock);
> > + rcu_read_unlock();
> > +}
>
> paul moore
- RGB
--
Richard Guy Briggs <rgb@...hat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
Powered by blists - more mailing lists