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=-2.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 16CABC4332B for ; Wed, 18 Mar 2020 21:42:28 +0000 (UTC) Received: from us-smtp-delivery-74.mimecast.com (us-smtp-delivery-74.mimecast.com [216.205.24.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BEE6A20714 for ; Wed, 18 Mar 2020 21:42:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="F2sfyVFE" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BEE6A20714 Authentication-Results: mail.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.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=1584567746; 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=ei/RSttxNFsDKKYchHTa6coDzoRI+yYydfHMV3Drduo=; b=F2sfyVFEKbPmp19GlClF/wus+aesB3sRPNegp9LPvUXIZOoQ/YA/5FF4IjL51l/9NNaVG0 ppCzxbYwxRnt/hU8NUEG42FZVH4NIcyKV7ykjEEsuCb0qVHTeXGGpuQecGxgq2vIlf2MWf laF9xcBxlOn55+xkkVphaTaB7RQ0d50= 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-349-ZH1TG-L6M8GrlYWGuHU1Yw-1; Wed, 18 Mar 2020 17:42:22 -0400 X-MC-Unique: ZH1TG-L6M8GrlYWGuHU1Yw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9A59A800D5E; Wed, 18 Mar 2020 21:42:18 +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 4BDCDBBBDB; Wed, 18 Mar 2020 21:42:18 +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 C047F18089CD; Wed, 18 Mar 2020 21:42:17 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 02ILgGP1007389 for ; Wed, 18 Mar 2020 17:42:16 -0400 Received: by smtp.corp.redhat.com (Postfix) id 57E945C3F8; Wed, 18 Mar 2020 21:42:16 +0000 (UTC) Received: from madcap2.tricolour.ca (unknown [10.36.110.5]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 65C105C1D8; Wed, 18 Mar 2020 21:41:59 +0000 (UTC) Date: Wed, 18 Mar 2020 17:41:54 -0400 From: Richard Guy Briggs To: Paul Moore Subject: Re: [PATCH ghak90 V8 07/16] audit: add contid support for signalling the audit daemon Message-ID: <20200318214154.ycxy5dl4pxno6fvi@madcap2.tricolour.ca> References: <20200204231454.oxa7pyvuxbj466fj@madcap2.tricolour.ca> <3142237.YMNxv0uec1@x2> <20200312202733.7kli64zsnqc4mrd2@madcap2.tricolour.ca> <20200313192306.wxey3wn2h4htpccm@madcap2.tricolour.ca> MIME-Version: 1.0 In-Reply-To: User-Agent: NeoMutt/20180716 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-loop: linux-audit@redhat.com Cc: nhorman@tuxdriver.com, linux-api@vger.kernel.org, containers@lists.linux-foundation.org, LKML , dhowells@redhat.com, linux-audit@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 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.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline On 2020-03-18 17:01, Paul Moore wrote: > On Fri, Mar 13, 2020 at 3:23 PM Richard Guy Briggs wrote: > > On 2020-03-13 12:42, Paul Moore wrote: > > ... > > > > The thread has had a lot of starts/stops, so I may be repeating a > > > previous suggestion, but one idea would be to still emit a "death > > > record" when the final task in the audit container ID does die, but > > > block the particular audit container ID from reuse until it the > > > SIGNAL2 info has been reported. This gives us the timely ACID death > > > notification while still preventing confusion and ambiguity caused by > > > potentially reusing the ACID before the SIGNAL2 record has been sent; > > > there is a small nit about the ACID being present in the SIGNAL2 > > > *after* its death, but I think that can be easily explained and > > > understood by admins. > > > > Thinking quickly about possible technical solutions to this, maybe it > > makes sense to have two counters on a contobj so that we know when the > > last process in that container exits and can issue the death > > certificate, but we still block reuse of it until all further references > > to it have been resolved. This will likely also make it possible to > > report the full contid chain in SIGNAL2 records. This will eliminate > > some of the issues we are discussing with regards to passing a contobj > > vs a contid to the audit_log_contid function, but won't eliminate them > > all because there are still some contids that won't have an object > > associated with them to make it impossible to look them up in the > > contobj lists. > > I'm not sure you need a full second counter, I imagine a simple flag > would be okay. I think you just something to indicate that this ACID > object is marked as "dead" but it still being held for sanity reasons > and should not be reused. Ok, I see your point. This refcount can be changed to a flag easily enough without change to the api if we can be sure that more than one signal can't be delivered to the audit daemon *and* collected by sig2. I'll have a more careful look at the audit daemon code to see if I can determine this. Steve, can you have a look and tell us if it is possible for the audit daemon to make more than one signal_info (or signal_info2) record request from the kernel after receiving a signal? Another question occurs to me is that what if the audit daemon is sent a signal and it cannot or will not collect the sig2 information from the kernel (SIGKILL?)? Does that audit container identifier remain dead until reboot, or do we institute some other form of reaping, possibly time-based? > 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 -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit