Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp847390ybv; Wed, 5 Feb 2020 15:53:27 -0800 (PST) X-Google-Smtp-Source: APXvYqzMYjuSPrb9K/4Dt7uBKHNBBuptufq3ncJtVVhUOH7za8n2AovawItcXK1xu7X1RCxguw2f X-Received: by 2002:a05:6808:315:: with SMTP id i21mr4738809oie.139.1580946807526; Wed, 05 Feb 2020 15:53:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580946807; cv=none; d=google.com; s=arc-20160816; b=jYCL3hHkxNi/yOAkojOpJupWVFrHQ/8TvLLwxWQQ28eICDFeXbXL5rSz1Y+lYRRXmr Nqvoa14KBb08BrKMjCVqGaonlzWEkY03Nhzp/PXunmki5uqoWHgL2EUT/oce9zesfUH5 GiSyitFA5GG+HvmuTHgkY/1oXQgIGuCeBNQGaFO/hIyFos3/bNjFrkRfg89jneRQ2VrZ oMZncITcHet54fmzib81S1Vb2on2TmPL5leUwmu32WeTsKZE3Aawdn77/mntGj9B5JlJ qpEqcNl8jBJKm5jC3outuV923UJs4FUWjf3/IsJJVrqUPwSNbIDG3YHVkLHajjmQESp+ q+3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=21qSowVJcxcWYCp2yjWV+jXV3rSeSLvAJHZEZIMcZO8=; b=VKdemOiEAee14LAZseODAUzLQrJsGb8mS5HXrj/cyZHC1X48vTJM3YxkXdW/ftxx+8 u0a539khXKC6jFvgPUt6sKFDPPCWtnZVveTIzUJAHjn15mSOWI9WdfYzXOYlubriuhxD XVajnC56z+fyKM4o2oygQK7WPXuYP+Q9VmPHoWhwmzpEiSS3DEHtVwxfH4m6wJiG/Qj0 9RzGlTfbQrX90TX9xwOwaAXPCkhUXdb9M/+3DvklIBKw1ILogAKYcIrxwkqN2l8dpi9U GTdjSvl6cGfcUBTO7OvHwsdyL1YXW1O1sp7GColePKB1xcRGMsiMxWmFVOXlsvnhgUIB qI3A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=h1pWFguP; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c5si742771otp.108.2020.02.05.15.53.15; Wed, 05 Feb 2020 15:53:27 -0800 (PST) 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=@redhat.com header.s=mimecast20190719 header.b=h1pWFguP; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727548AbgBEXvU (ORCPT + 99 others); Wed, 5 Feb 2020 18:51:20 -0500 Received: from us-smtp-1.mimecast.com ([207.211.31.81]:43765 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727149AbgBEXvU (ORCPT ); Wed, 5 Feb 2020 18:51:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1580946678; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=21qSowVJcxcWYCp2yjWV+jXV3rSeSLvAJHZEZIMcZO8=; b=h1pWFguPbN02Ienyvor0Re50q9TPTzst85NB1D5034p+s3M8kzrG67dAwbHN7/pv9TkXOQ po/C5O3g2njKggOT6ltJHM1gPGFB3iC8woGc5IauqnyMIXXOg0bcjQ27HZ9byxmnXAlvJ4 cU3WJONYtgy6ccmtBd6wPKaRyQF5Jzk= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-355-uJE-8bYYPnuJj-bwv06u2Q-1; Wed, 05 Feb 2020 18:51:14 -0500 X-MC-Unique: uJE-8bYYPnuJj-bwv06u2Q-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 50DE71800D42; Wed, 5 Feb 2020 23:51:11 +0000 (UTC) Received: from madcap2.tricolour.ca (ovpn-112-16.rdu2.redhat.com [10.10.112.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 85FA160BF7; Wed, 5 Feb 2020 23:50:59 +0000 (UTC) Date: Wed, 5 Feb 2020 18:50:56 -0500 From: Richard Guy Briggs To: Paul Moore Cc: nhorman@tuxdriver.com, linux-api@vger.kernel.org, containers@lists.linux-foundation.org, LKML , dhowells@redhat.com, Linux-Audit Mailing List , netfilter-devel@vger.kernel.org, ebiederm@xmission.com, simo@redhat.com, netdev@vger.kernel.org, linux-fsdevel@vger.kernel.org, Eric Paris , mpatel@redhat.com, Serge Hallyn Subject: Re: [PATCH ghak90 V8 13/16] audit: track container nesting Message-ID: <20200205235056.e5365xtgz7rbese2@madcap2.tricolour.ca> References: <6452955c1e038227a5cd169f689f3fd3db27513f.1577736799.git.rgb@redhat.com> <20200130192753.n7jjrshbhrczjzoe@madcap2.tricolour.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-02-05 18:05, Paul Moore wrote: > On Thu, Jan 30, 2020 at 2:28 PM Richard Guy Briggs wrote: > > On 2020-01-22 16:29, Paul Moore wrote: > > > On Tue, Dec 31, 2019 at 2:51 PM Richard Guy Briggs wrote: > > > > > > > > Track the parent container of a container to be able to filter and > > > > report nesting. > > > > > > > > Now that we have a way to track and check the parent container of a > > > > container, modify the contid field format to be able to report that > > > > nesting using a carrat ("^") separator to indicate nesting. The > > > > original field format was "contid=" for task-associated records > > > > and "contid=[,[...]]" for network-namespace-associated > > > > records. The new field format is > > > > "contid=[^[...]][,[...]]". > > > > > > Let's make sure we always use a comma as a separator, even when > > > recording the parent information, for example: > > > "contid=[,^[...]][,[...]]" > > > > The intent here is to clearly indicate and separate nesting from > > parallel use of several containers by one netns. If we do away with > > that distinction, then we lose that inheritance accountability and > > should really run the list through a "uniq" function to remove the > > produced redundancies. This clear inheritance is something Steve was > > looking for since tracking down individual events/records to show that > > inheritance was not aways feasible due to rolled logs or search effort. > > Perhaps my example wasn't clear. I'm not opposed to the little > carat/hat character indicating a container's parent, I just think it > would be good to also include a comma *in*addition* to the carat/hat. Ah, ok. Well, I'd offer that it would be slightly shorter, slightly less cluttered and having already written the parser in userspace, I think the parser would be slightly simpler. I must admit, I was a bit puzzled by your snippet of code that was used as a prefix to the next item rather than as a postfix to the given item. Can you say why you prefer the comma in addition? > > > > Signed-off-by: Richard Guy Briggs > > > > --- > > > > include/linux/audit.h | 1 + > > > > kernel/audit.c | 53 +++++++++++++++++++++++++++++++++++++++++++-------- > > > > kernel/audit.h | 1 + > > > > kernel/auditfilter.c | 17 ++++++++++++++++- > > > > kernel/auditsc.c | 2 +- > > > > 5 files changed, 64 insertions(+), 10 deletions(-) > > > > > > ... > > > > > > > diff --git a/kernel/audit.c b/kernel/audit.c > > > > index ef8e07524c46..68be59d1a89b 100644 > > > > --- a/kernel/audit.c > > > > +++ b/kernel/audit.c > > > > > > > @@ -492,6 +493,7 @@ void audit_switch_task_namespaces(struct nsproxy *ns, struct task_struct *p) > > > > audit_netns_contid_add(new->net_ns, contid); > > > > } > > > > > > > > +void audit_log_contid(struct audit_buffer *ab, u64 contid); > > > > > > If we need a forward declaration, might as well just move it up near > > > the top of the file with the rest of the declarations. > > > > Ok. > > > > > > +void audit_log_contid(struct audit_buffer *ab, u64 contid) > > > > +{ > > > > + struct audit_contobj *cont = NULL, *prcont = NULL; > > > > + int h; > > > > > > It seems safer to pass the audit container ID object and not the u64. > > > > It would also be faster, but in some places it isn't available such as > > for ptrace and signal targets. This also links back to the drop record > > refcounts to hold onto the contobj until process exit, or signal > > delivery. > > > > What we could do is to supply two potential parameters, a contobj and/or > > a contid, and have it use the contobj if it is valid, otherwise, use the > > contid, as is done for names and paths supplied to audit_log_name(). > > Let's not do multiple parameters, that begs for misuse, let's take the > wrapper function route: > > func a(int id) { > // important stuff > } > > func ao(struct obj) { > a(obj.id); > } > > ... and we can add a comment that you *really* should be using the > variant that passes an object. I was already doing that where it available, and dereferencing the id for the call. But I see an advantage to having both parameters supplied to the function, since it saves us the trouble of dereferencing it, searching for the id in the hash list and re-locating the object if the object is already available. > > > > @@ -2705,9 +2741,10 @@ int audit_set_contid(struct task_struct *task, u64 contid) > > > > if (!ab) > > > > return rc; > > > > > > > > - audit_log_format(ab, > > > > - "op=set opid=%d contid=%llu old-contid=%llu", > > > > - task_tgid_nr(task), contid, oldcontid); > > > > + audit_log_format(ab, "op=set opid=%d contid=", task_tgid_nr(task)); > > > > + audit_log_contid(ab, contid); > > > > + audit_log_format(ab, " old-contid="); > > > > + audit_log_contid(ab, oldcontid); > > > > > > This is an interesting case where contid and old-contid are going to > > > be largely the same, only the first (current) ID is going to be > > > different; do we want to duplicate all of those IDs? > > > > At first when I read your comment, I thought we could just take contid > > and drop oldcontid, but if it fails, we still want all the information, > > so given the way I've set up the search code in userspace, listing only > > the newest contid in the contid field and all the rest in oldcontid > > could be a good compromise. > > This is along the lines of what I was thinking. Good. > 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