Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp1046400ybh; Wed, 18 Mar 2020 14:00:11 -0700 (PDT) X-Google-Smtp-Source: ADFU+vvIFEBzXvrJpBtuPFc7c2NYPcivHofm8m6SlTfdXnEy28098XQ14tKh3e6roED4QH8j1G8p X-Received: by 2002:aca:d446:: with SMTP id l67mr4876060oig.115.1584565211248; Wed, 18 Mar 2020 14:00:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584565211; cv=none; d=google.com; s=arc-20160816; b=KJtHC3AKGQfkkZXfhI+GaAdwLXXv8KclwkpJ6jRADg+57RY/HmR0pc3BFFeKOvDjPl SRRZIQjj+WCgFTM+fnOqypz2sOsVUcBQEWjNv3ICc06NTluTInIEYZS4W5+/dQSOO6DN kjwjw0I8/4pOSca0Xr7g4TDRsY0hjMtVpJeHGIK02fTp4jyEYVKDlGUo8+I1EjI+R0Nw tTkkbv3X08Q59ydk0eDcwoQbQfEc6uInZpdSGv879lHT7R8I2pM5o1f50WPx/4R/xoty ooYx8o+Pjzq3X5K/2snOw0Mkp+2bIirm/ORHCwgYUEvgnzOLlGjao5mD9CBJa2HHUhIS 1rvg== 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=g4AW1divsHMPr3pCP4CdP4Cl7K8Ooaeq6pBA6GUaETQ=; b=svC6WItvVFK1ghrCHQOPiCs1vleW8wNS5YlQ/nXWSZA9ZkQYk+DwTxk7tMAqwcR4GS NUnxW3ptXdVa0CtIaSOr8bXndzuUeXIBwCHr4QuN1BhAzP2UhZ32BALge2Nb6+STobUi Ez3/z6tmf/MDsmGmDxpnq3kECEBMy+N+h52CQRw3BAT1r78jpzLEx+Dq1X8XJPvqLan+ FM9+baQlOR/IRtNIdsMUfN4FSVxaMePIJF6xgaTNHNjgbRPO4eAgReuLsAwq4XfFifw4 lZiv+CK07FLbBRTwOETQOLjwAfsHi7knhbRWoRr+kjPDPtWNAXlzgsOrWlk63WIDsoVh 3Tqg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=vKUVcXTV; 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 o7si57888otk.185.2020.03.18.13.59.57; Wed, 18 Mar 2020 14:00:11 -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=vKUVcXTV; 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 S1728451AbgCRU6z (ORCPT + 99 others); Wed, 18 Mar 2020 16:58:55 -0400 Received: from mail-ed1-f66.google.com ([209.85.208.66]:36201 "EHLO mail-ed1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728744AbgCRU47 (ORCPT ); Wed, 18 Mar 2020 16:56:59 -0400 Received: by mail-ed1-f66.google.com with SMTP id b18so28099384edu.3 for ; Wed, 18 Mar 2020 13:56:58 -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=g4AW1divsHMPr3pCP4CdP4Cl7K8Ooaeq6pBA6GUaETQ=; b=vKUVcXTVLCHqGtHDPpcfyVqC7Iyjswe5s6J8QA9fOEK3HpHui7X1QKcUp6EbQ9CrJA C05DjEwPknqFMwyMxVdqOASL4j0b74tzhGVN0rVlDcTqP9r+6muRk44tUHGBiJX0FH3l 0kSJ6xSo1oAI9qxQ9gvTZog0w8m3+yD8qjRaTynTXcNhuDoADAvpXa2+efq0e6D5YD6n 3CHbsifYNfb0CcekkOIbFkd9XH2x71AkNHltG81Un5wU3LND7OYeks7yEgdlSRFl1uJ5 VwR+O1FlMTPjN3UY4K4PQO/XHK+MSLNlCxZ0KmE3m5D5D1kIPJi19WSDxOhR1iInmt9f 77jw== 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=g4AW1divsHMPr3pCP4CdP4Cl7K8Ooaeq6pBA6GUaETQ=; b=nu7YZ8QxE9iUyi/YWAvwpLsKjONCEtaRng2iOmib6JA3WUl4erlfbOaM5zuuuJne/N Vw85PULrwQUQZTTMV8WJbA+0fH+DYPucrVsXFhAAJz79E3a7qhoXV6qUYyOR6Mafimz6 LbXj9aPsZm6IfsZwT2ruwcWFg5DFJpQJOj0nLFp5psf3VQFdcKJq1DuTP3TZe17XJML/ qBMO4t0LHsWg0eEoinP8V+oEPAYQiy9FAV2SJELXnuIhL3j96ygP03N5/kDho8UiLnnH F76V/pQ1zCY5mShEvidjxMK5YSWO+bSjXS1JjUvNQDZD2d9gm2Wv1w7/Uwehy+8CVvri Vs1g== X-Gm-Message-State: ANhLgQ0dioL5Phudp9W5lnfmqbjiwACs/J8nEq8RFcpr8czMe3NY3grP Wx9+sqbRrWPJ/ESbhri436UB+BRxq2J1UpDTTWei X-Received: by 2002:a17:906:7b8d:: with SMTP id s13mr120333ejo.77.1584565017755; Wed, 18 Mar 2020 13:56:57 -0700 (PDT) MIME-Version: 1.0 References: <20200204231454.oxa7pyvuxbj466fj@madcap2.tricolour.ca> <3142237.YMNxv0uec1@x2> <20200312193037.2tb5f53yeisfq4ta@madcap2.tricolour.ca> <20200313185900.y44yvrfm4zxa5lfk@madcap2.tricolour.ca> In-Reply-To: <20200313185900.y44yvrfm4zxa5lfk@madcap2.tricolour.ca> From: Paul Moore Date: Wed, 18 Mar 2020 16:56:46 -0400 Message-ID: Subject: Re: [PATCH ghak90 V8 07/16] audit: add contid support for signalling the audit daemon To: Richard Guy Briggs Cc: Steve Grubb , linux-audit@redhat.com, nhorman@tuxdriver.com, linux-api@vger.kernel.org, containers@lists.linux-foundation.org, LKML , dhowells@redhat.com, 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 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 13, 2020 at 2:59 PM Richard Guy Briggs wrote: > On 2020-03-13 12:29, Paul Moore wrote: > > On Thu, Mar 12, 2020 at 3:30 PM Richard Guy Briggs wrote: > > > On 2020-02-13 16:44, Paul Moore wrote: > > > > This is a bit of a thread-hijack, and for that I apologize, but > > > > another thought crossed my mind while thinking about this issue > > > > further ... Once we support multiple auditd instances, including the > > > > necessary record routing and duplication/multiple-sends (the host > > > > always sees *everything*), we will likely need to find a way to "trim" > > > > the audit container ID (ACID) lists we send in the records. The > > > > auditd instance running on the host/initns will always see everything, > > > > so it will want the full container ACID list; however an auditd > > > > instance running inside a container really should only see the ACIDs > > > > of any child containers. > > > > > > Agreed. This should be easy to check and limit, preventing an auditd > > > from seeing any contid that is a parent of its own contid. > > > > > > > For example, imagine a system where the host has containers 1 and 2, > > > > each running an auditd instance. Inside container 1 there are > > > > containers A and B. Inside container 2 there are containers Y and Z. > > > > If an audit event is generated in container Z, I would expect the > > > > host's auditd to see a ACID list of "1,Z" but container 1's auditd > > > > should only see an ACID list of "Z". The auditd running in container > > > > 2 should not see the record at all (that will be relatively > > > > straightforward). Does that make sense? Do we have the record > > > > formats properly designed to handle this without too much problem (I'm > > > > not entirely sure we do)? > > > > > > I completely agree and I believe we have record formats that are able to > > > handle this already. > > > > I'm not convinced we do. What about the cases where we have a field > > with a list of audit container IDs? How do we handle that? > > I don't understand the problem. (I think you crossed your 1/2 vs > A/B/Y/Z in your example.) ... It looks like I did, sorry about that. > ... Clarifying the example above, if as you > suggest an event happens in container Z, the hosts's auditd would report > Z,^2 > and the auditd in container 2 would report > Z,^2 > but if there were another auditd running in container Z it would report > Z > while the auditd in container 1 or A/B would see nothing. Yes. My concern is how do we handle this to minimize duplicating and rewriting the records? It isn't so much about the format, although the format is a side effect. -- paul moore www.paul-moore.com