From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CDA25C2BA2B for ; Thu, 16 Apr 2020 21:53:56 +0000 (UTC) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 83B2F217D8 for ; Thu, 16 Apr 2020 21:53:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="VlryViMn" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 83B2F217D8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=paul-moore.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linux-audit-bounces@redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1587074035; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=XScXoA3x8w9/vMRvEtnmBLCioBphp2N0HhvSi9/g5YY=; b=VlryViMnQqMYK0L/dmBFBIVG0H4e21XWU0y3I9Yzok0tixdAYeP5qz5zt44Xy/LLAJqksx ZHMukSXjdTzbIJwrEckyONGHS68JhRPh4+WXuyB+gdLMX9fyk4UbZ0uf4oIlUpZSulJKRE Y5FZmu7IaZtKMVPVpEfdQuLR5Dpv4MI= 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-479-bfCqnGH9NgyA1Sy9eIFNAA-1; Thu, 16 Apr 2020 17:53:53 -0400 X-MC-Unique: bfCqnGH9NgyA1Sy9eIFNAA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 318BB107ACC4; Thu, 16 Apr 2020 21:53:50 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6EC0B1000325; Thu, 16 Apr 2020 21:53:49 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id D5AA118034EA; Thu, 16 Apr 2020 21:53:45 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 03GLrfLr004835 for ; Thu, 16 Apr 2020 17:53:41 -0400 Received: by smtp.corp.redhat.com (Postfix) id 412742026E1C; Thu, 16 Apr 2020 21:53:41 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast05.extmail.prod.ext.rdu2.redhat.com [10.11.55.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3D2472026D66 for ; Thu, 16 Apr 2020 21:53:39 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 5308B800296 for ; Thu, 16 Apr 2020 21:53:39 +0000 (UTC) Received: from mail-ej1-f68.google.com (mail-ej1-f68.google.com [209.85.218.68]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-60-ukKx79JjNaqcYfUMc1plYg-1; Thu, 16 Apr 2020 17:53:36 -0400 X-MC-Unique: ukKx79JjNaqcYfUMc1plYg-1 Received: by mail-ej1-f68.google.com with SMTP id q8so21668eja.2 for ; Thu, 16 Apr 2020 14:53:36 -0700 (PDT) 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=eUNGgddkQnrL1o2hsZswaMALGVl9JsvHDg1XmEFxRXs=; b=UIH+QOU9EQTVeGWjUP0KG+87jW2NOGzIAur52Vvcoevnlh1LwnuNHpJMnhoQSp8HVe USuI7+s+j7LyWbD2rc9MSBTY6aDao+84WrwnIF7A5fDFQu3qhACwQqSy6jlAcArUYE7d gHicqiDZQ95ACGmVwMBuwouEIcbTuy1GetrxBTTvRJmt5NlOWfDdM5xkZwkSCUykjc9V OanMAScYwrMsxgKJjjuTdPdlifhl52GWoSM3Vw4YMXmj8YO48x1nmXWtCQPYPYJyyKRg ahA6OB3anxFgaesABToLBaTlbJCug4Fn3QlY3ilhs7CsnJmCKMz4oGF3tdPgZdN8OWJP 9KJA== X-Gm-Message-State: AGi0PuZnBxa3wE3I+50YrtNI4BJKc3F9SoX3YW9UiHtjj36jn4KMgCpC ywUZ5Wzb38WRyG/MTQczBtMLIoGzG9ll5gwVapn2 X-Google-Smtp-Source: APiQypL+BE3uA1SW0Bujmyp0BjjA9VEPrFMXVzQljtvXfQzPxFQdYF4edXGWSKCfJiLORwzoe3+Py9YdpYXjI/hRt+E= X-Received: by 2002:a17:906:d7a2:: with SMTP id pk2mr118612ejb.272.1587074015141; Thu, 16 Apr 2020 14:53:35 -0700 (PDT) MIME-Version: 1.0 References: <20200318215550.es4stkjwnefrfen2@madcap2.tricolour.ca> <20200319220249.jyr6xmwvflya5mks@madcap2.tricolour.ca> <20200324210152.5uydf3zqi3dwshfu@madcap2.tricolour.ca> <20200330134705.jlrkoiqpgjh3rvoh@madcap2.tricolour.ca> <20200330162156.mzh2tsnovngudlx2@madcap2.tricolour.ca> <20200330174937.xalrsiev7q3yxsx2@madcap2.tricolour.ca> <871ronf9x2.fsf@x220.int.ebiederm.org> In-Reply-To: <871ronf9x2.fsf@x220.int.ebiederm.org> From: Paul Moore Date: Thu, 16 Apr 2020 17:53:23 -0400 Message-ID: Subject: Re: [PATCH ghak90 V8 07/16] audit: add contid support for signalling the audit daemon To: "Eric W. Biederman" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-MIME-Autoconverted: from quoted-printable to 8bit by lists01.pubmisc.prod.ext.phx2.redhat.com id 03GLrfLr004835 X-loop: linux-audit@redhat.com Cc: nhorman@tuxdriver.com, Richard Guy Briggs , linux-api@vger.kernel.org, containers@lists.linux-foundation.org, LKML , dhowells@redhat.com, linux-audit@redhat.com, netfilter-devel@vger.kernel.org, simo@redhat.com, netdev@vger.kernel.org, linux-fsdevel@vger.kernel.org, Eric Paris , mpatel@redhat.com, Serge Hallyn X-BeenThere: linux-audit@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Linux Audit Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Thu, Apr 16, 2020 at 4:36 PM Eric W. Biederman wrote: > Paul Moore writes: > > On Mon, Mar 30, 2020 at 1:49 PM Richard Guy Briggs wrote: > >> On 2020-03-30 13:34, Paul Moore wrote: > >> > On Mon, Mar 30, 2020 at 12:22 PM Richard Guy Briggs wrote: > >> > > On 2020-03-30 10:26, Paul Moore wrote: > >> > > > On Mon, Mar 30, 2020 at 9:47 AM Richard Guy Briggs wrote: > >> > > > > On 2020-03-28 23:11, Paul Moore wrote: > >> > > > > > On Tue, Mar 24, 2020 at 5:02 PM Richard Guy Briggs wrote: > >> > > > > > > On 2020-03-23 20:16, Paul Moore wrote: > >> > > > > > > > On Thu, Mar 19, 2020 at 6:03 PM Richard Guy Briggs wrote: > >> > > > > > > > > On 2020-03-18 18:06, Paul Moore wrote: > > > > ... > > > >> > > Well, every time a record gets generated, *any* record gets generated, > >> > > we'll need to check for which audit daemons this record is in scope and > >> > > generate a different one for each depending on the content and whether > >> > > or not the content is influenced by the scope. > >> > > >> > That's the problem right there - we don't want to have to generate a > >> > unique record for *each* auditd on *every* record. That is a recipe > >> > for disaster. > >> > > >> > Solving this for all of the known audit records is not something we > >> > need to worry about in depth at the moment (although giving it some > >> > casual thought is not a bad thing), but solving this for the audit > >> > container ID information *is* something we need to worry about right > >> > now. > >> > >> If you think that a different nested contid value string per daemon is > >> not acceptable, then we are back to issuing a record that has only *one* > >> contid listed without any nesting information. This brings us back to > >> the original problem of keeping *all* audit log history since the boot > >> of the machine to be able to track the nesting of any particular contid. > > > > I'm not ruling anything out, except for the "let's just completely > > regenerate every record for each auditd instance". > > Paul I am a bit confused about what you are referring to when you say > regenerate every record. > > Are you saying that you don't want to repeat the sequence: > audit_log_start(...); > audit_log_format(...); > audit_log_end(...); > for every nested audit daemon? If it can be avoided yes. Audit performance is already not-awesome, this would make it even worse. > Or are you saying that you would like to literraly want to send the same > skb to each of the nested audit daemons? Ideally we would reuse the generated audit messages as much as possible. Less work is better. That's really my main concern here, let's make sure we aren't going to totally tank performance when we have a bunch of nested audit daemons. > Or are you thinking of something else? As mentioned above, I'm not thinking of anything specific, other than let's please not have to regenerate *all* of the audit record strings for each instance of an audit daemon, that's going to be a killer. Maybe we have to regenerate some, if we do, what would that look like in code? How do we handle the regeneration aspect? I worry that is going to be really ugly. Maybe we finally burn down the audit_log_format(...) function and pass structs/TLVs to the audit subsystem and the audit subsystem generates the strings in the auditd connection thread. Some of the record strings could likely be shared, others would need to be ACID/auditd dependent. I'm open to any ideas people may have. We have a problem, let's solve it. -- paul moore www.paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit