Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp1082030ybh; Wed, 18 Mar 2020 14:44:40 -0700 (PDT) X-Google-Smtp-Source: ADFU+vtZVcvTptk5WxqAHitgzJJrZpBWTbsTFvTCXkmarKIkG4MakZg5evh9L5c/m1kELjW1pN3w X-Received: by 2002:aca:1b11:: with SMTP id b17mr63539oib.4.1584567879887; Wed, 18 Mar 2020 14:44:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584567879; cv=none; d=google.com; s=arc-20160816; b=N1cqutujni8w8IiNg44qieTaOOsqPCu/aINpkP24l9BySCiEPZQyE6A8my++0BsnfI 4bSEJkSo++s6OBA15RtS1XGfSNJLxS2WTQlhZATImPOdB5Z426m6ZRKGZGLj4ljr4seT qwLwDdNmtIWL6BxSmSck7iRENO6fKkAYDXpQulBE2PVChjzBSiu/ptK5Dua4lkq2NmU+ Ww3IOOryhYq5BrAdCnx65k1DbYJ9GkGm3T8nT8cw7SEQt0i2fLG3RAUguhvfgyOG4KvC QqSJpIQzc5hHUXlBlJaRP4HTC4hiJRPU7h9o/M7J18Cpg1jdnUUUqfVOVdG4E/hZ6tP3 gwmw== 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=wywIpBmnfonP+SMsK60nELfMnC1movwf9uyeVdD853s=; b=Umv9Uqm/RojbyGc/xEN4LSv/K0v2n2D5BlJPhbYUZ7U7AoADR4lfssQ7h6oXTcjam/ uPdpPCoby9eTMIl2rbpyYrBOQSpgQ/co/bJCWrn1uIiv8KhTkArfoO03VOnzG07vfpdJ Fq6ErHBA63B0Zs2hPl4tsHwg2MFW08LoajVzZz1khGLSC0GiFz6H5QMzZ7esZnpu6AU8 kp3qkLi6Zfrw2JTI4wJT+7fO0WK2i2TqlD978jy/xUuP5tverb4RsT4zaMF01uBtJZXj eRhdThDhVPbhUnV49LE5+pufR6dthYkJNFIXSz+/b5bS0crwVs/NqcFSV0u88HcGNjjh mQYg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=T6mq9rK5; 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 l185si4139651oif.274.2020.03.18.14.44.26; Wed, 18 Mar 2020 14:44:39 -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=T6mq9rK5; 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 S1727304AbgCRVmm (ORCPT + 99 others); Wed, 18 Mar 2020 17:42:42 -0400 Received: from mail-ed1-f67.google.com ([209.85.208.67]:36543 "EHLO mail-ed1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727283AbgCRVmm (ORCPT ); Wed, 18 Mar 2020 17:42:42 -0400 Received: by mail-ed1-f67.google.com with SMTP id b18so10944edu.3 for ; Wed, 18 Mar 2020 14:42:40 -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=wywIpBmnfonP+SMsK60nELfMnC1movwf9uyeVdD853s=; b=T6mq9rK5P4XpQWpFfgAiIKi3lH6pQ6GrbiqcMaiWfr84rHUjaBgAPLyvhXpYETE4kf hcDCkpv1bWurwcrlC+pdyLmJ7HjGj+jJTTPLOsi6OPDpp0OhaCzlySAOEoFzgwsLyNve riGrdxe9qj9V/sK9YGkwAhJvugJjcnoZunY6ijk+/FC40Niqe/7YKhSYc/e0cJNueFZ6 MLKmmruNYdIFErSAF28rG/44y7aci8x84AylNieoqtKWrsl83QneKNR/oymmyR1uTUtV 2im+8o6LX4BTBghxmI4mwpR0taGPa67j5MS5vEGJtUTSOhmOUdMg9kiIEOBCoyS9T79h wuYQ== 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=wywIpBmnfonP+SMsK60nELfMnC1movwf9uyeVdD853s=; b=TEF4YU10AmCv8ocwNAQEQ6L8+ubuCwnIKJ8LHVR0BWdPQOoKdMtYUm2aW5N+hN95pA 3eBIwlRdoO5LVnqSOEb0dzpU4Tz8jZzycOdoJ/JOzRDjeGlu98zSxz/Jdn+GQPWvduvT /q44qR9e84bO7pDWyGQCQAKy7BnmQYzHj7ajLj/3Fn0fM+Tc1bvIAJ7bbfONU4Ir98FI KMoD4yizxa9ZhryYuqDqudUw4i54fCvHAA9zHUPt1l8kM1DrqUFEEqLQ4JT90USZRfbH 9W2xfX1T7n8IXo5ZH3XuPHtVlQ99SlJspL/MvaolIZQVRXWgpRbblJ9XW7qKlTG2aJi0 s8Nw== X-Gm-Message-State: ANhLgQ1/qnCvA/zz++h/t9vnN6Lomuj49ABVre28msyBoOAONyqYKPgd ycHK0zTKUlnpqhIpSAJ/md4+6EeqAPcvutYP2PZ3 X-Received: by 2002:aa7:dd01:: with SMTP id i1mr5988476edv.164.1584567759671; Wed, 18 Mar 2020 14:42:39 -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> <20200318212630.mw2geg4ykhnbtr3k@madcap2.tricolour.ca> In-Reply-To: <20200318212630.mw2geg4ykhnbtr3k@madcap2.tricolour.ca> From: Paul Moore Date: Wed, 18 Mar 2020 17:42:28 -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 Wed, Mar 18, 2020 at 5:27 PM Richard Guy Briggs wrote: > On 2020-03-18 16:56, Paul Moore wrote: > > 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. > > Are you talking about caching, or about divulging more information than > necessary or even information leaks? Or even noticing that records that > need to be generated to two audit daemons share the same contid field > values and should be generated at the same time or information shared > between them? I'd see any of these as optimizations that don't affect > the api. Imagine a record is generated in a container which has more than one auditd in it's ancestry that should receive this record, how do we handle that without completely killing performance? That's my concern. If you've already thought up a plan for this - excellent, please share :) -- paul moore www.paul-moore.com