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,URIBL_BLOCKED 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 76184C2BA2B for ; Thu, 16 Apr 2020 20:40:05 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 064CC221F4 for ; Thu, 16 Apr 2020 20:40:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="ZQknTlsJ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 064CC221F4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=xmission.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=1587069603; 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=OV3h59kyow/IEawNqbBcABBLaQknRnERo3vGPNwGWLc=; b=ZQknTlsJ88coJjLt037LLmeHZ+pW+LCLXgF5KGwooa4iL5kBLrSOTtuP6STF/PJAqkcFd/ zDXTkbB7AlJVXsO7cwp6ZS4zob6Y0AaduuefGcvpgRg41z9OcZehZeh1u6yOVmhds9WaG0 VUJKIpBAB2oowKWcbLVTnk1ijUx48Q4= 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-366-Ki4XucgrOb24gcGfjfisrg-1; Thu, 16 Apr 2020 16:39:59 -0400 X-MC-Unique: Ki4XucgrOb24gcGfjfisrg-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 24B2A107ACCC; Thu, 16 Apr 2020 20:39:55 +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 BB9E0100EBA7; Thu, 16 Apr 2020 20:39:53 +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 C2C6818034E9; Thu, 16 Apr 2020 20:39:52 +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 03GKaRFK031133 for ; Thu, 16 Apr 2020 16:36:27 -0400 Received: by smtp.corp.redhat.com (Postfix) id 24FB02026E1C; Thu, 16 Apr 2020 20:36:27 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast01.extmail.prod.ext.rdu2.redhat.com [10.11.55.17]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 20B672026D66 for ; Thu, 16 Apr 2020 20:36:25 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) (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 1E2708056CE for ; Thu, 16 Apr 2020 20:36:25 +0000 (UTC) Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-179-Fnd7BckmOiaJd_T3ydSxOg-1; Thu, 16 Apr 2020 16:36:21 -0400 X-MC-Unique: Fnd7BckmOiaJd_T3ydSxOg-1 Received: from in01.mta.xmission.com ([166.70.13.51]) by out03.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jPBF9-0003Wf-Lk; Thu, 16 Apr 2020 14:36:15 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=x220.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1jPBF8-0008Kz-Fm; Thu, 16 Apr 2020 14:36:15 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Paul Moore 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> Date: Thu, 16 Apr 2020 15:33:13 -0500 In-Reply-To: (Paul Moore's message of "Mon, 30 Mar 2020 15:55:36 -0400") Message-ID: <871ronf9x2.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 X-XM-SPF: eid=1jPBF8-0008Kz-Fm; ; ; mid=<871ronf9x2.fsf@x220.int.ebiederm.org>; ; ; hst=in01.mta.xmission.com; ; ; ip=68.227.160.95; ; ; frm=ebiederm@xmission.com; ; ; spf=neutral X-XM-AID: U2FsdGVkX18QCbICEec/DdkpMxCQSiOIlOx7aNlCCNU= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH ghak90 V8 07/16] audit: add contid support for signalling the audit daemon X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) 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 03GKaRFK031133 X-loop: linux-audit@redhat.com X-Mailman-Approved-At: Thu, 16 Apr 2020 16:39:51 -0400 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 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? Or are you saying that you would like to literraly want to send the same skb to each of the nested audit daemons? Or are you thinking of something else? Eric -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit