Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3887253yba; Tue, 9 Apr 2019 06:54:18 -0700 (PDT) X-Google-Smtp-Source: APXvYqxGOg4OcgCx3onj7cyUaR/BulY4+6yR7D5+5L/+JDXSSfiATk+EVREfCZiWVl/KDqtYiUXv X-Received: by 2002:a63:be02:: with SMTP id l2mr32946913pgf.48.1554818058124; Tue, 09 Apr 2019 06:54:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554818058; cv=none; d=google.com; s=arc-20160816; b=b4rEuYP9bjuazptw9dxVp6LlRmwX9aSDKvZpQhER5aF0bhIpX87EiSeFBI2Hy13VG+ 4/UJeOLsLrGTxETgA9dbsUlNoedO2thK+zUCLx9axWYSFLk/k06hO4QOnf48Tpe4jtNR wB9zvnxt3LxwS4a5LXlA491fDUzAtxTRCXVRSd3rJ0Fux+JkFhvtIo8m8l3QzwI6ntqQ Q7UugsEcTW2igxNAiNrjeh/vvA+mfBzXQ7an1LfVpzVqfE8X1uVNa67NUOGCpKDBPj+M kF/E4a0ifaQlOW3/NoTeRxAatHdfGkZyWeWzByNWYyQsNK0PtTGFDhwK6bJW38gG/2LI M48w== 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; bh=p6CehQ6gz/96qt9V/SkakZqUVoEWXgzyrzrYaGPRRUA=; b=iji3YvxNORA+RgZMa2LWyxnoQRK9HJt1gWijQKN7eitRuJbIHQ+e0kGB3TnC+zcVZB 7NF4yUudgQv5z7FHgnN5NpgkaIZ0F7KR0npLWD0rIMx8Pzh8lK175GEAN7ISFcWhAEhD sO3LmraSDKB4x6Aa5CzgSn1Q1d4IKQvi5+8fr3+ijxaczmutJp71l0KMopZ/IHDNEAql g1a30tFJRQp4du7heK76zb10YpXpVvtzZWJmD5qxBD1DxD2vXVgftdGgw1v796YHNdHV hlGFvZ3ExHXMf7hvUMiiVf+C0/y5IAGXwkYw57hzla9gPLYc4NHLgwoclhQHyqqp9rc8 drMQ== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (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 m128si29250360pga.142.2019.04.09.06.54.00; Tue, 09 Apr 2019 06:54:18 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726494AbfDINxV (ORCPT + 99 others); Tue, 9 Apr 2019 09:53:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10228 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726112AbfDINxV (ORCPT ); Tue, 9 Apr 2019 09:53:21 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C0F7A307D978; Tue, 9 Apr 2019 13:53:20 +0000 (UTC) Received: from madcap2.tricolour.ca (ovpn-112-16.phx2.redhat.com [10.3.112.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1B89C5C28D; Tue, 9 Apr 2019 13:53:06 +0000 (UTC) Date: Tue, 9 Apr 2019 09:53:04 -0400 From: Richard Guy Briggs To: Paul Moore Cc: Ondrej Mosnacek , containers@lists.linux-foundation.org, linux-api@vger.kernel.org, Linux-Audit Mailing List , linux-fsdevel@vger.kernel.org, LKML , netdev@vger.kernel.org, netfilter-devel@vger.kernel.org, Steve Grubb , David Howells , Simo Sorce , Eric Paris , "Serge E. Hallyn" , "Eric W . Biederman" , nhorman@tuxdriver.com Subject: Re: [PATCH ghak90 V6 05/10] audit: add contid support for signalling the audit daemon Message-ID: <20190409135304.rgkcpgya6h3ciphy@madcap2.tricolour.ca> References: 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.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.48]); Tue, 09 Apr 2019 13:53:21 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019-04-09 09:40, Paul Moore wrote: > On Tue, Apr 9, 2019 at 8:58 AM Ondrej Mosnacek wrote: > > On Tue, Apr 9, 2019 at 5:40 AM Richard Guy Briggs wrote: > > > Add audit container identifier support to the action of signalling the > > > audit daemon. > > > > > > Since this would need to add an element to the audit_sig_info struct, > > > a new record type AUDIT_SIGNAL_INFO2 was created with a new > > > audit_sig_info2 struct. Corresponding support is required in the > > > userspace code to reflect the new record request and reply type. > > > An older userspace won't break since it won't know to request this > > > record type. > > > > > > Signed-off-by: Richard Guy Briggs > > > > This looks good to me. > > > > Reviewed-by: Ondrej Mosnacek > > > > Although I'm wondering if we shouldn't try to future-proof the > > AUDIT_SIGNAL_INFO2 format somehow, so that we don't need to add > > another AUDIT_SIGNAL_INFO3 when the need arises to add yet-another > > identifier to it... The simplest solution I can come up with is to add > > a "version" field at the beginning (set to 2 initially), then v_len > > at the beginning of data for version . But maybe this is too > > complicated for too little gain... > > FWIW, I believe the long term solution to this is the fabled netlink > attribute approach that we haven't talked about in some time, but I > keep dreaming about (it has been mostly on the back burner becasue 1) > time and 2) didn't want to impact the audit container ID work). While > I'm not opposed to trying to make things like this a bit more robust > by adding version fields and similar things, there are still so many > (so very many) problems with the audit kernel/userspace interface that > still need to be addressed. While this particular message type is used very infrequently, adding a version field to every message type strikes me as a huge overhead for the small likelihood of the format needing to change. I'd prefer to just key it off the AUDIT_FEATURE_BITMAP or some other easily detectable change in this distinguishing feature, such as the presence of /proc/self/audit_containerid, which is what I've done in the accompanying userspace patchset that I'm preparing to post that works with this change. Neil, you are right that netlink has useful mechanisms to help with this sort of thing, but we're not quite there yet. > 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