Received: by 10.192.165.148 with SMTP id m20csp1278319imm; Sat, 21 Apr 2018 05:15:00 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/VnH4/cWXVVLrMsp5/jkfzDiL6mUY7rLaxPJhxYsv3jBC+F7r8ELyR1X8r+eweFeOlmkh8 X-Received: by 10.99.97.150 with SMTP id v144mr11447831pgb.264.1524312900682; Sat, 21 Apr 2018 05:15:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524312900; cv=none; d=google.com; s=arc-20160816; b=l5lc2BAupq4tqU3f6XsROCpoigXW03nh856sj/CNzu/s9MTuVFdgl8M+uthNN2okXj JOfeyp8faTLCQUYMO7tpUuBxc2FY3OLesDBcq1PUOE7kVb+hHj9Zoksz7hGQ5HEWG4Qm dt3/mvO0LIWFTnsekH6CqfecF6T8bqenGjJglJqR74dpO04YUmOr5ysF59Ckew0fltkg 2Bm7U3diJC0kXZqw1N7k3d03ZU2I0pA54P551nDHCyk6+M4hm/8OAo6cBA6oEcwoLUW2 W0NNUVANpHj8JRRj44ABcWT/3iC8zMaWDU/o16dV7P3Yxbg5b+ql5dRSMQ+/L0gktB1k rdwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :subject:user-agent:references:in-reply-to:message-id:date:cc:to :from:dkim-signature:arc-authentication-results; bh=C6Mcdt3ra2eYHIxNm34pP109gX1wNKl3EAZcNRE9HGk=; b=L58Dim16qr8DiTRYfPVmDeHmJ24yzV3sVSpIb1e6LtcyHhHqjhLpc3WgUL9KeeZelM jo6g7ujQecfruNKctufmrtaurWEPDf1MAwUooALawnmaBeItGy/rP6Z/vkYQb9KTkBOH 3eLIz4V4C5BRjdX8/76MGskLzLn6vytXCpJXZzS5qrUq7Kc9DaYxPMkvzkczpEfi8vJ3 CeP17GTQE1tIRTpgUwbBkCf7NHC9Vbioi5PtiBw58GzSBnvpLrHsbgPjX+cHLJ3GBpPv XIYhBiFipetW+3bN74M8ABMNPVDKg8t9GUrM9vjmnKasw2fWtMLw/+iIhLckkoNrQGHb 3XEg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=K+Hsg/h+; 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 c76si6526447pga.156.2018.04.21.05.14.09; Sat, 21 Apr 2018 05:15:00 -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=K+Hsg/h+; 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 S1752754AbeDUMK4 (ORCPT + 99 others); Sat, 21 Apr 2018 08:10:56 -0400 Received: from mail-io0-f193.google.com ([209.85.223.193]:34478 "EHLO mail-io0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752241AbeDUMKw (ORCPT ); Sat, 21 Apr 2018 08:10:52 -0400 Received: by mail-io0-f193.google.com with SMTP id d6-v6so13412339iog.1 for ; Sat, 21 Apr 2018 05:10:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:date:message-id:in-reply-to:references:user-agent :subject:mime-version:content-transfer-encoding; bh=C6Mcdt3ra2eYHIxNm34pP109gX1wNKl3EAZcNRE9HGk=; b=K+Hsg/h+ZcAsjY43WxOApBXP13QmfkwuLmwQLECmhTg3JzqZL0TKmqO2o58g+OzlKG hxIPmPmK2QJioXI7DWJEhx5fCDYZyw47NU3pmJZ7/szFChUkb3oSUCvjegs0uWj6kjX3 DtN3knOQ6KKF5Hr98rQ0hsFFigfhUl2hwiiB7VhytjkFCuypMMr2i2E5SwL0vygm9ifT B48LdVtPKCIVK4ERK7lNZLePBNlw5p9EfqZ72TUoTmzXjTdUqO2Yje8tL0ilsjwDOekk jiWjeci92Ff/3kOlJV0uDDSxdvA2tSeNTxuv/Y5WhT3tJ+lh2VRFcwBoo+H0sgER+SNM h7WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:date:message-id:in-reply-to :references:user-agent:subject:mime-version :content-transfer-encoding; bh=C6Mcdt3ra2eYHIxNm34pP109gX1wNKl3EAZcNRE9HGk=; b=L6yLt+jL1r+NsNFV5BipXRbk8A1DS0n0jyiX8uXk1IsuAx2cb2Q6QQlrft7W/0HARv HIvstAy1bhIi0pwagLykrJj9CcFemVmtG9CkKKKIGDCWldZTOVJDfiBdVlghmiKL1O4V RCY0Mu1fTbkalIn8HqNAPpQDKxQ6T+dGk0z8gMF28jihfe5Ulm087AJpsP1sVDB/R35p YJGR1qUrAivziLxUiq3ZT90o/Fwc1ht01U3BnnFPacyd0WGch7hScqUFXK4VzCuVuc7g xzSZ9Yj1vm0lZ6FF9RUwHiUT6Q+TxswWpLFCpPPnoInmQPs4lWdEwrLNpUSTzTLkLpjn PoIg== X-Gm-Message-State: ALQs6tCo5cSPQyYmu5NKmTyjvMCk8+zoFp3WliyYFtpShQgX/ni8503q Xf7BM71izE0hrEjSm4SizY+c X-Received: by 2002:a6b:c002:: with SMTP id q2-v6mr13911694iof.53.1524312651395; Sat, 21 Apr 2018 05:10:51 -0700 (PDT) Received: from [10.217.216.217] (mobile-166-170-23-14.mycingular.net. [166.170.23.14]) by smtp.gmail.com with ESMTPSA id d135-v6sm1884537ita.15.2018.04.21.05.10.48 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 21 Apr 2018 05:10:49 -0700 (PDT) From: Paul Moore To: Richard Guy Briggs CC: , , , , , LKML , Eric Paris , , "Linux-Audit Mailing List" , , , , , , , Date: Sat, 21 Apr 2018 08:10:46 -0400 Message-ID: <162e81d2170.280e.85c95baa4474aabc7814e68940a78392@paul-moore.com> In-Reply-To: <20180420204225.iik2lgtj6gx2ep4w@madcap2.tricolour.ca> References: <11b43a498e768a14764594c808a96b34d52be0af.1521179281.git.rgb@redhat.com> <20180420200226.7tyxzuovdbgclw3m@madcap2.tricolour.ca> <20180420204225.iik2lgtj6gx2ep4w@madcap2.tricolour.ca> User-Agent: AquaMail/1.14.2-840 (build: 101400201) Subject: Re: [RFC PATCH ghak32 V2 11/13] audit: add support for containerid to network namespaces MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On April 20, 2018 4:48:34 PM Richard Guy Briggs wrote: On 2018-04-20 16:22, Paul Moore wrote: 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_st= ruct *tsk) struct nsproxy *old_ns =3D tsk->nsproxy; struct user_namespace *user_ns =3D task_cred_xxx(tsk, user_ns); struct nsproxy *new_ns; + u64 containerid =3D 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_st= ruct *tsk) return PTR_ERR(new_ns); tsk->nsproxy =3D 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. The new namespace hasn't been cloned yet and this is the only function where we have access to both namespaces, so I don't see how that could work... I'll take another, closer look, with v3. paul moore - RGB -- Richard Guy Briggs 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 -- paul moore www.paul-moore.com