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=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 6FCFAC4332D for ; Wed, 18 Mar 2020 21:01:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3DD9120409 for ; Wed, 18 Mar 2020 21:01:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=paul-moore-com.20150623.gappssmtp.com header.i=@paul-moore-com.20150623.gappssmtp.com header.b="m+CruKFq" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728779AbgCRVBq (ORCPT ); Wed, 18 Mar 2020 17:01:46 -0400 Received: from mail-ed1-f66.google.com ([209.85.208.66]:45241 "EHLO mail-ed1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728862AbgCRVBk (ORCPT ); Wed, 18 Mar 2020 17:01:40 -0400 Received: by mail-ed1-f66.google.com with SMTP id u59so4272154edc.12 for ; Wed, 18 Mar 2020 14:01:37 -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=h1JVSDR71Ka3PM04u0ramfobv1CKoUTWgjm5qfW2CV8=; b=m+CruKFqyeFiSzmQCZqiAjkeem718D1Unt4LZxrLyM48zoGD0gDaVn0NlVfCexVTzu wihdula0cgpJNes9gbbbPZGOCr8gmzgfMR1DP2niKlc4/Xbz1RjMvIcZK3QeYS4MTBzR VGVmqZmbPsEQ42JahCXbnk6yopm5byhYxfuE4bMF2/oEIwfi0TIGwhWzo+tUFEv5Mobg xAZqhXW9ZYNPl8K7ISeE3z29hhnh0uDlXFQhZXWxMxod1HlKG5GyxdS8a7Q7I9YuWv4C hEdfpxYwsjziy7uL5etvx6svflsV0+OWDJH1g09o69UnURs0B4B8khAkiIXSB+T2BP9R 8WWg== 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=h1JVSDR71Ka3PM04u0ramfobv1CKoUTWgjm5qfW2CV8=; b=NSnONfdyxDVNs2Y5HWPY+/HnjCER2W7aq4kfK9tKlM+6Xb6EsW4mEsd+ylFo1kxabi ahV/b3M9DJWbD+htsQeLuwxXB/+ezlqJWm+lVr8hzs/vvMaJa5phtsYqGNnE06pjUO+W lZSiZAy9A6IiHBRVw7KQGgs5wCm8AOImeGm4D7IcKGa7v+uDyZek0LkWgH8Jo0qmY5Q4 f6l//Gr7NUnk4vz+nSkuo/oceQrmwKDJb+hMDHhleKMe+gL3aJoDJuq+S22BdVTvzDNU hnHh0ivdVeCDZoeXgf6mHKtZkZ2SXr1rfQoQJMdT/Krt6UU5FsLFItb4xXpvBR4U6MF4 896A== X-Gm-Message-State: ANhLgQ2xR9qUOqxpT7zyACj6omC+K0Yzkc3L4vIV4Gb9r3zlrZF2QTRt 9lAyOC22BBXUTCioz+aFwjakdzIF5nSxrBiEFhs6 X-Google-Smtp-Source: ADFU+vtjoB1L41gbvG3IfZm3ksBmDTvbqLdnYvpmD27Ya9UPhKm77W68IFm4/AxRz3i7hA2sUofnKwQPP6SAVhHtg78= X-Received: by 2002:a05:6402:8c3:: with SMTP id d3mr5966134edz.31.1584565297053; Wed, 18 Mar 2020 14:01:37 -0700 (PDT) MIME-Version: 1.0 References: <20200204231454.oxa7pyvuxbj466fj@madcap2.tricolour.ca> <3142237.YMNxv0uec1@x2> <20200312202733.7kli64zsnqc4mrd2@madcap2.tricolour.ca> <20200313192306.wxey3wn2h4htpccm@madcap2.tricolour.ca> In-Reply-To: <20200313192306.wxey3wn2h4htpccm@madcap2.tricolour.ca> From: Paul Moore Date: Wed, 18 Mar 2020 17:01:26 -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 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. -- paul moore www.paul-moore.com