Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp2518588ybb; Mon, 30 Mar 2020 07:42:56 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsken73IApciDqihGJx9quXbdWLTX15vlwkBSX+1ipCqFQ/gvrgmmKAShE0ukl1Cpz0u+6e X-Received: by 2002:aca:3986:: with SMTP id g128mr7397423oia.3.1585579376334; Mon, 30 Mar 2020 07:42:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585579376; cv=none; d=google.com; s=arc-20160816; b=RocwBiond3TKoRVnhc9j+gjJSCCFKMMGpuq8tE8Wah3tL5Hs0OTqsfbkD28Gz83E0M MhpZwUEV0JqwMFYKjKM+BD/I6JOpIGyJ2dMT381gtvDYRtyYSMblTecW4GxZuaiFJTl6 gRFgj+RHLuJCM7DvPr50CJbFXiSAvq7S+6hRyp0bfk1cmeRaNq32jeUFOxldXBgk1GIP j8BJrUNx1KVREPI/8Wh+qHkMplX6lCIkJipzIVLb8tlORxqqRT9kJOHI+SCqgW3UXDtN zscHWDSH8WbAimgH2YjNhTT3n0fMtC5al+DrfisZ+4q5mpzN+RjBD1RXjqWaE7rii0HF 7JLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=nIwHXYaHc6+JACA+fBj9Ng03i5CGrWKmbD2K5DI9CIE=; b=pXrPCPZunqajmzITvJWluQra271fGFA4Vc8tVJXGi44dsEbkaNvPW1UZUKDkF+P00C B1pk0ESwX/y6veNKQxwMXs0r3VfT1G/jIYcgaRBslsdBxvbn6tv2WSdvXAhZiDP7Q5w5 GM+NRVonTz8wb9zEUag1l0FX/RoCRjpReQNPbsDWhz4smFD2gReDvyDFhni7Tzny8eP/ DuwcvkVRyFryTbF/9DYvjeqkBg9LHs6Sb0h3Avp3FcYTn6+Z5crk3UP3ciwrZ1Dh8TsS bXlLRBku38ub2iWIRC0syg6VpWWAB7pLBhpJa+CSlpeFmvucYkgaoaFHpDZdgTxykDV0 rnjg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=ajvRh38G; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g188si1842046oia.203.2020.03.30.07.42.42; Mon, 30 Mar 2020 07:42:56 -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=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=ajvRh38G; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728812AbgC3O0q (ORCPT + 99 others); Mon, 30 Mar 2020 10:26:46 -0400 Received: from mail-ed1-f65.google.com ([209.85.208.65]:44027 "EHLO mail-ed1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727899AbgC3O0p (ORCPT ); Mon, 30 Mar 2020 10:26:45 -0400 Received: by mail-ed1-f65.google.com with SMTP id bd14so20767798edb.10 for ; Mon, 30 Mar 2020 07:26:44 -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=nIwHXYaHc6+JACA+fBj9Ng03i5CGrWKmbD2K5DI9CIE=; b=ajvRh38GUf77mUItDVx5WbVN3YYFvjpLhHpwTv84kBQrU1zHTfXiaouPYDLxmTBG45 8MfOdRSj5sryUlWJASFBkFehPbzj8g+e0VLiclXWIZ4G7TNuAWnOLRZsHy5ZILaeErIk LqDtUQMsHOq4lmfzrcPHMubNv/dsDfNl88x3vGdvlTcKgkieRjEG7LJI1fd9nz6RqZu5 BOFFrhLvSD3REAwMRyI7d5+5fdIIBNKMwpnUqrTKVhUtpQqIoLekud+8zPPbmsCM+lt0 dRMyhqGXKHl96BJACIDgeCHLcpYrgLmsx7K26Jot1RzI/1+tsWiYSF1NdBH7pmfmhUq/ WEgQ== 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=nIwHXYaHc6+JACA+fBj9Ng03i5CGrWKmbD2K5DI9CIE=; b=f4ZjeWmmoAa4m23m4TvVSNusRbU5OzjPpT+3obV50aVPaQxNZevnMD+LnBMMJcTduJ SsEomKfe7YyIZgbKmeciclFLh07pGktLLcFZgWVNlnbTs0owxrKafPu2CEE8jrzqN8VX 5wVQdA+X5CasmHSV/ouhrLgiNqU1OCbKoiJTEmW3HNagKnehhyxHzwmAzPMnyi//RpNz D6zsZcUl1Nve1Ay+ULO0wp4AvX8Ts7cpiGvPFlseVKlJfthYxQDijZOsKc7VHd0RUV/q Ytyo08dZNZ6jT0H4XCyIOJER0xBmK1NUd6guVCFqsU+mkaKwW9K3z+6K8/ZC2rqxEKWI /9ww== X-Gm-Message-State: ANhLgQ3IUCgEgDj+zTA5di5OTkCqOqB4G0AJvG2IxCcBm5Yej3tD/9jK T8wK0mW5PCoUh6VmIsSsuqHdXrEGZ62I/uzTJsdL X-Received: by 2002:aa7:c48f:: with SMTP id m15mr9786550edq.164.1585578403828; Mon, 30 Mar 2020 07:26:43 -0700 (PDT) MIME-Version: 1.0 References: <20200313185900.y44yvrfm4zxa5lfk@madcap2.tricolour.ca> <20200318212630.mw2geg4ykhnbtr3k@madcap2.tricolour.ca> <20200318215550.es4stkjwnefrfen2@madcap2.tricolour.ca> <20200319220249.jyr6xmwvflya5mks@madcap2.tricolour.ca> <20200324210152.5uydf3zqi3dwshfu@madcap2.tricolour.ca> <20200330134705.jlrkoiqpgjh3rvoh@madcap2.tricolour.ca> In-Reply-To: <20200330134705.jlrkoiqpgjh3rvoh@madcap2.tricolour.ca> From: Paul Moore Date: Mon, 30 Mar 2020 10:26:34 -0400 Message-ID: Subject: Re: [PATCH ghak90 V8 07/16] audit: add contid support for signalling the audit daemon To: Richard Guy Briggs 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 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 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: > > > > > > > > ... > > > > > > > > > > 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. > > > > Perhaps I'm remembering your latest spin of these patches incorrectly, > > but there is still a big gap between when the record is generated and > > when it is sent up to the audit daemon. Most importantly in that gap > > is the whole big queue/multicast/unicast mess. > > So you suggest generating that record on the fly once it reaches the end > of the audit_queue just before being sent? That sounds... disruptive. > Each audit daemon is going to have its own queues, so by the time it > ends up in a particular queue, we'll already know its scope and would > have the right list of contids to print in that record. I'm not suggesting any particular solution, I'm just pointing out a potential problem. It isn't clear to me that you've thought about how we generate a multiple records, each with the correct ACID list intended for a specific audit daemon, based on a single audit event. Explain to me how you intend that to work and we are good. Be specific because I'm not convinced we are talking on the same plane here. -- paul moore www.paul-moore.com