Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp1222213ybg; Tue, 2 Jun 2020 04:36:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxJ9kFb21muldEBA3rlc30rpw83kQt4LY5jwqpJ4e1mYgdYmRzzpwEiTGgkfJTYtt42gQDq X-Received: by 2002:a17:906:6897:: with SMTP id n23mr917196ejr.437.1591097807996; Tue, 02 Jun 2020 04:36:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591097807; cv=none; d=google.com; s=arc-20160816; b=QlAk1r2f+DoemMfdgfqJ2tqKHGSQtWLrNFgQNYpLtZwzfN8T5Lj4ebE0jmKHGoq7hp VifKMo+6+VDlrVaib4nH+1/bJ/Q0fRUZGDoDrNzhqaPXrkBhkcjuqJZhgDDwKJYZzke3 zL6JspT1DKo0WteyWn6AlwvDWHmx9Lb4DxSuJAdHY8M3PoDYNktZjFcdz5CK2LcmTRZe miaSVLlF+yOo1a8tS8JYXE5sZEBJBb5BrrvxdXV/fjE2NP21FAot9fzO0XZOkChReWzQ JWo0lZwxLh3sUErsXy48DLW+FQ9+eUxFzwqirXqI4MyP/KA8s5Xh0sB72ZToeozpMRyQ SeiA== 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=APPso8SmvnnOp4Dv0Sfkx5AFaSya8aWECXtjHdRoMxM=; b=QcFDVAPAHBGcuXRkB3KyZOYZOjc5TyfVqmNqtdcedGRTeOOTkIQyE8qW6hVLOX4GTv 8qWE+su7S0m0Syle4WW8uADu2UPhPifTMVJ2H8DpBERKfPmvnpM8D+vFAT6E3wAjVAup IySxKM4ga8rJIiPMWOhRPlxmX0AIbiWo3JuCEXNSza7lJAS5PjBP9DJPt8wUuGcDi8H9 qHbDwcd2hrGmOQBi6A0rofIPV1AllWhSg7CQTjvDgqHkaM7puzh9KVWEuMlDEsLTklHN wUaPTOSI8wz0CBWnx9dSJoppMuuTrJsw4qImeaP3CQEJQ/JuAx3FWRJ4FePHNxrz/L0s HaCQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=YA7kCI9h; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id p3si1436095edr.104.2020.06.02.04.36.24; Tue, 02 Jun 2020 04:36:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=YA7kCI9h; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1726728AbgFBLef (ORCPT + 99 others); Tue, 2 Jun 2020 07:34:35 -0400 Received: from us-smtp-2.mimecast.com ([207.211.31.81]:24400 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726130AbgFBLef (ORCPT ); Tue, 2 Jun 2020 07:34:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591097673; 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=APPso8SmvnnOp4Dv0Sfkx5AFaSya8aWECXtjHdRoMxM=; b=YA7kCI9hGHNTAF/ouKGAxb7pZ6Fap8WvgQl6/zGJvThST9yZPt9KvYr0F0y3jL6H2/0MuX 2O0fgUCVPShn9HIAzP0KcWnhK3qjzaGvwiCXkFMrpvUh4IaPuqmZaKSOaGf3gC/pXtWhbB OyTc0rMX1serB7Mxhh/9x/tEy3ttD0Y= 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-437-omEDP3A6MjuDFhd3Dccq6A-1; Tue, 02 Jun 2020 07:34:29 -0400 X-MC-Unique: omEDP3A6MjuDFhd3Dccq6A-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 20E0518FE864; Tue, 2 Jun 2020 11:34:28 +0000 (UTC) Received: from madcap2.tricolour.ca (unknown [10.10.110.54]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 402B4579A3; Tue, 2 Jun 2020 11:34:19 +0000 (UTC) Date: Tue, 2 Jun 2020 07:34:17 -0400 From: Richard Guy Briggs To: Paul Moore Cc: Linux-Audit Mailing List , LKML , netfilter-devel@vger.kernel.org, sgrubb@redhat.com, Ondrej Mosnacek , fw@strlen.de, twoerner@redhat.com, Eric Paris , tgraf@infradead.org Subject: Re: [PATCH ghak124 v2] audit: log nftables configuration change events Message-ID: <20200602113417.kfrmwm57snkaiv3y@madcap2.tricolour.ca> References: <20200601225833.ut2wayc6xqefwveo@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.79 on 10.5.11.13 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-06-01 20:12, Paul Moore wrote: > On Mon, Jun 1, 2020 at 6:58 PM Richard Guy Briggs wrote: > > On 2020-06-01 12:10, Paul Moore wrote: > > > On Thu, May 28, 2020 at 9:44 PM Richard Guy Briggs wrote: > > ... > > > > > diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c > > > > index 4471393da6d8..7a386eca6e04 100644 > > > > --- a/net/netfilter/nf_tables_api.c > > > > +++ b/net/netfilter/nf_tables_api.c > > > > @@ -12,6 +12,7 @@ > > > > #include > > > > #include > > > > #include > > > > +#include > > > > #include > > > > #include > > > > #include > > > > @@ -693,6 +694,14 @@ static void nf_tables_table_notify(const struct nft_ctx *ctx, int event) > > > > { > > > > struct sk_buff *skb; > > > > int err; > > > > + char *buf = kasprintf(GFP_KERNEL, "%s:%llu;?:0", > > > > + ctx->table->name, ctx->table->handle); > > > > + > > > > + audit_log_nfcfg(buf, > > > > + ctx->family, > > > > + ctx->table->use, > > > > + audit_nftcfgs[event].op); > > > > > > As an example, the below would work, yes? > > > > > > audit_log_nfcfg(..., > > > (event == NFT_MSG_NEWTABLE ? > > > AUDIT_NFT_OP_TABLE_REGISTER : > > > AUDIT_NFT_OP_TABLE_UNREGISTER) > > > > Ok, I see what you are getting at now... Yes, it could be done this > > way, but it seems noisier to me. > > I'll admit it is not as clean, but it doesn't hide the mapping between > the netfilter operation and the audit operation which hopefully makes > it clear to those modifying the netfilter/nf_tables/etc. code that > there is an audit impact. I'm basically trying to make sure the code > is as robust as possible in the face of subsystem changes beyond the > audit subsystem. Yup, I agree, a compile time check to make sure they aren't out of sync. > 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