Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp5266293ybb; Tue, 24 Mar 2020 14:03:44 -0700 (PDT) X-Google-Smtp-Source: ADFU+vvquF0A+a10AG40kV9iUIr7jh5vP6gh2v0ag8yqsvS7iExmlN699Q2FoMB+usyHCAmKqwCi X-Received: by 2002:aca:4fc3:: with SMTP id d186mr115630oib.171.1585083824239; Tue, 24 Mar 2020 14:03:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585083824; cv=none; d=google.com; s=arc-20160816; b=l+RtAWlmx5j0TJ7UEfCNEGzaghv641Mxd/6TaZEI7O4OnkglmiZxdQMIB7BdWM+0Xg 6xKUP7MmA4RemWKdIWD3MKXbGRWKkqZV3K3QX/baKv2VPXcGy0gaH84/UFpezQ6fcU20 y3quWIhD6qFwV9Pm12DxpcEKeaGoSg3Ky7WRNiZWaXcxi9v93pHZX9glbVO2BEBga98y HdrQ2BSUl2rEqQSnRkScz2IzFyG8XcOKfakIE3THEJQgJXExZphxz9biNj8d9Vt1SjXA 16oGBKv9nu68FjVrWNIINkk8XCsBiTVOdt8vrg/CL3itEzIks7ASLzpFjk2kYzyHE1Du URDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=ezORt9tWKqavsqost0+8jwF+irEVoobXTNyqmEmYnCY=; b=U6ApApFJnZ8xaH1ESvzGxnJXQxL1eVASIzDlpcwJ/5PRye3E20/6CaDOjEgypMZNUx X6BH2SvZWCSliXr/GC+mT/VuGU72mTqse0WJ1pqqUxbZofga71M366Klm8U8o0+15t92 7PhjqOLrFmymZ75joIglHLuWsroPGVxF4fMNHhaohpi7B7xdAZDzuswGn3DfVz8vAGIl WK6ezjSCk2iSD4Go+GpxBUCgg55sIxTGi6qHwjv2enfqVT9Qt8JDJM5QvKTtOMB2H0X/ 5Kp9Va/nrJvGY41dMeiEZFqLZIDpnnxjlPPwyDT1x5AASMq9DsvYy0ZtM+kKczYTPgC0 VSmw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=JAa65Qbt; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d75si9619388oib.22.2020.03.24.14.03.17; Tue, 24 Mar 2020 14:03:44 -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=@redhat.com header.s=mimecast20190719 header.b=JAa65Qbt; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727980AbgCXVCQ (ORCPT + 99 others); Tue, 24 Mar 2020 17:02:16 -0400 Received: from us-smtp-delivery-74.mimecast.com ([216.205.24.74]:32506 "EHLO us-smtp-delivery-74.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727613AbgCXVCP (ORCPT ); Tue, 24 Mar 2020 17:02:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1585083734; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ezORt9tWKqavsqost0+8jwF+irEVoobXTNyqmEmYnCY=; b=JAa65QbtlGo9vHlvtafvPopAQ6x4otyEMGJ/ycLmejJmBnypEpWR/49ss1qjKojiAl/tgw vHYgMR1u3Up/ncRo3Y0TEaLxZ/1cbjXZ9VwuPr96tpeVpeIUsnmuIaZhMKnvJUzmA2lKV5 uUaLdEWZJP+sKD7L/1r4oQH4RbZ9aKI= 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-289-qKNTB0YPNMSuZYrUnbJeZQ-1; Tue, 24 Mar 2020 17:02:10 -0400 X-MC-Unique: qKNTB0YPNMSuZYrUnbJeZQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CEFF8189D6C0; Tue, 24 Mar 2020 21:02:08 +0000 (UTC) Received: from madcap2.tricolour.ca (unknown [10.10.110.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4FADC19925; Tue, 24 Mar 2020 21:01:54 +0000 (UTC) Date: Tue, 24 Mar 2020 17:01:52 -0400 From: Richard Guy Briggs To: Paul Moore 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 Subject: Re: [PATCH ghak90 V8 07/16] audit: add contid support for signalling the audit daemon Message-ID: <20200324210152.5uydf3zqi3dwshfu@madcap2.tricolour.ca> References: <20200312193037.2tb5f53yeisfq4ta@madcap2.tricolour.ca> <20200313185900.y44yvrfm4zxa5lfk@madcap2.tricolour.ca> <20200318212630.mw2geg4ykhnbtr3k@madcap2.tricolour.ca> <20200318215550.es4stkjwnefrfen2@madcap2.tricolour.ca> <20200319220249.jyr6xmwvflya5mks@madcap2.tricolour.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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: > > ... > > > > I hope we can do better than string manipulations in the kernel. I'd > > > much rather defer generating the ACID list (if possible), than > > > generating a list only to keep copying and editing it as the record is > > > sent. > > > > At the moment we are stuck with a string-only format. > > Yes, we are. That is another topic, and another set of changes I've > been deferring so as to not disrupt the audit container ID work. > > I was thinking of what we do inside the kernel between when the record > triggering event happens and when we actually emit the record to > userspace. Perhaps we collect the ACID information while the event is > occurring, but we defer generating the record until later when we have > a better understanding of what should be included in the ACID list. > It is somewhat similar (but obviously different) to what we do for > PATH records (we collect the pathname info when the path is being > resolved). Ok, now I understand your concern. In the case of NETFILTER_PKT records, the CONTAINER_ID record is the only other possible record and they are generated at the same time with a local context. In the case of any event involving a syscall, that CONTAINER_ID record is generated at the time of the rest of the event record generation at syscall exit. The others are only generated when needed, such as the sig2 reply. We generally just store the contobj pointer until we actually generate the CONTAINER_ID (or CONTAINER_OP) record. > 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