Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp833270ybg; Mon, 1 Jun 2020 16:01:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxmkdtWxrO0US6as4CLuIjUa16CLgwt3CWtnw4zLNUSjNvVhiV6w+Veap4xhC85GSINSATC X-Received: by 2002:a17:906:d111:: with SMTP id b17mr11906146ejz.267.1591052476766; Mon, 01 Jun 2020 16:01:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591052476; cv=none; d=google.com; s=arc-20160816; b=j8tzQWGX1ObrYYkXo5OwxG+Z9ls2EbXhOvPEKXImNrb9CSAGQmhd6dmQXoSOJyDHil 9C1E1UONniJP2jmmGeB5j5ZM3ryuRcYSt2GRzEBmZnVBNFpG1dSc8wNUmRshNW4etl7j cBoJG8ONg5yGHMCbYgFI2UiMVsv+zLxEGheVR8DegEt6t8WrTEQK3ZtlNU5LpmmljBv4 VmfDxM1n2E2nqEX+XWEoU2k0RrLuekqRb3QlL/F8cQLF8iGc6JdveyVj5VGidwnGigrW LiTJPsQPFlV+dfXa8BNmJdDuJQLq3mNlbGu+vr8IWz9zjTOyMlnlqVHZ/tKe51eV9tcD 1lXw== 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=KQYWfj8uLyxoKfXSZak9oNxGL8NYLL/ZT3WXC4WUx7Y=; b=mw40+m1BL8eHEOmJ7MjG6igpXEKU17OdVrkOI6KU01dpL/YfNiPKQACM7F0sxs9hv1 j9WlRik+IJK0e5nlgoWy8ap4q+OjdIBA5Z9tnUYF4n3jNa66nl9vPHFwa2wjQ7nCNzyH lPbtVbhPGSA1cBBKJw175NtNRtYxYF3QQKHSP0tGHRRmW2EVPrIGhhP1pw9/tm6lQUHk bPM3yQq6ACf5n2f1xYsRs9RM+1WnWXRqY409z8Fvp0M8hdTLi8QkycYq0kFDeTzwurB6 3d+F8lbVN1GZIChqUQ0CErLW9r6P0CPpQbKcGO/Em3d0Dly9OyrmYixytr6Kxy9U7Vbq KGoQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=KmHxa0yv; 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 h26si476709edj.196.2020.06.01.16.00.53; Mon, 01 Jun 2020 16:01:16 -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=KmHxa0yv; 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 S1728202AbgFAW7D (ORCPT + 99 others); Mon, 1 Jun 2020 18:59:03 -0400 Received: from us-smtp-1.mimecast.com ([205.139.110.61]:43045 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725766AbgFAW7D (ORCPT ); Mon, 1 Jun 2020 18:59:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591052340; 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=KQYWfj8uLyxoKfXSZak9oNxGL8NYLL/ZT3WXC4WUx7Y=; b=KmHxa0yvsbANRzETNosVtMVG01UeQrjAGuWUA9rxXNwAZ/ukcMCcAYUWkErEjSpm5ATxHP gpelLLNLv/FP4F1ZvBaVlPhmk2pQrkZQP/30MSN4YsA35FKKys3ZdbBxb0+011ZIxfN7hm SxmEjDWMewEdrW7DauYJn3kTePkObI8= 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-182-VGwIx79sPo-7OnnSuSc8CA-1; Mon, 01 Jun 2020 18:58:45 -0400 X-MC-Unique: VGwIx79sPo-7OnnSuSc8CA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 063A280B72E; Mon, 1 Jun 2020 22:58:44 +0000 (UTC) Received: from madcap2.tricolour.ca (unknown [10.10.110.54]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1DE915D9C9; Mon, 1 Jun 2020 22:58:35 +0000 (UTC) Date: Mon, 1 Jun 2020 18:58:33 -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: <20200601225833.ut2wayc6xqefwveo@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.14 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-06-01 12:10, Paul Moore wrote: > On Thu, May 28, 2020 at 9:44 PM Richard Guy Briggs wrote: > > iptables, ip6tables, arptables and ebtables table registration, > > replacement and unregistration configuration events are logged for the > > native (legacy) iptables setsockopt api, but not for the > > nftables netlink api which is used by the nft-variant of iptables in > > addition to nftables itself. > > > > Add calls to log the configuration actions in the nftables netlink api. > > > > This uses the same NETFILTER_CFG record format but overloads the table > > field. > > > > type=NETFILTER_CFG msg=audit(2020-05-28 17:46:41.878:162) : table=?:0;?:0 family=unspecified entries=2 op=nft_register_gen pid=396 subj=system_u:system_r:firewalld_t:s0 comm=firewalld > > ... > > type=NETFILTER_CFG msg=audit(2020-05-28 17:46:41.878:162) : table=firewalld:1;?:0 family=inet entries=0 op=nft_register_table pid=396 subj=system_u:system_r:firewalld_t:s0 comm=firewalld > > ... > > type=NETFILTER_CFG msg=audit(2020-05-28 17:46:41.911:163) : table=firewalld:1;filter_FORWARD:85 family=inet entries=8 op=nft_register_chain pid=396 subj=system_u:system_r:firewalld_t:s0 comm=firewalld > > ... > > type=NETFILTER_CFG msg=audit(2020-05-28 17:46:41.911:163) : table=firewalld:1;filter_FORWARD:85 family=inet entries=101 op=nft_register_rule pid=396 subj=system_u:system_r:firewalld_t:s0 comm=firewalld > > ... > > type=NETFILTER_CFG msg=audit(2020-05-28 17:46:41.911:163) : table=firewalld:1;__set0:87 family=inet entries=87 op=nft_register_setelem pid=396 subj=system_u:system_r:firewalld_t:s0 comm=firewalld > > ... > > type=NETFILTER_CFG msg=audit(2020-05-28 17:46:41.911:163) : table=firewalld:1;__set0:87 family=inet entries=0 op=nft_register_set pid=396 subj=system_u:system_r:firewalld_t:s0 comm=firewalld > > > > For further information please see issue > > https://github.com/linux-audit/audit-kernel/issues/124 > > > > Signed-off-by: Richard Guy Briggs > > --- > > Changelog: > > v2: > > - differentiate between xtables and nftables > > - add set, setelem, obj, flowtable, gen > > - use nentries field as appropriate per type > > - overload the "tables" field with table handle and chain/set/flowtable > > > > include/linux/audit.h | 52 +++++++++++++++++++++++++ > > kernel/auditsc.c | 24 ++++++++++-- > > net/netfilter/nf_tables_api.c | 89 +++++++++++++++++++++++++++++++++++++++++++ > > 3 files changed, 162 insertions(+), 3 deletions(-) > > > > diff --git a/include/linux/audit.h b/include/linux/audit.h > > index 3fcd9ee49734..d79866a38505 100644 > > --- a/include/linux/audit.h > > +++ b/include/linux/audit.h > > @@ -12,6 +12,7 @@ > > #include > > #include > > #include > > +#include > > > > #define AUDIT_INO_UNSET ((unsigned long)-1) > > #define AUDIT_DEV_UNSET ((dev_t)-1) > > @@ -98,6 +99,57 @@ enum audit_nfcfgop { > > AUDIT_XT_OP_REGISTER, > > AUDIT_XT_OP_REPLACE, > > AUDIT_XT_OP_UNREGISTER, > > + AUDIT_NFT_OP_TABLE_REGISTER, > > + AUDIT_NFT_OP_TABLE_UNREGISTER, > > + AUDIT_NFT_OP_CHAIN_REGISTER, > > + AUDIT_NFT_OP_CHAIN_UNREGISTER, > > + AUDIT_NFT_OP_RULE_REGISTER, > > + AUDIT_NFT_OP_RULE_UNREGISTER, > > + AUDIT_NFT_OP_SET_REGISTER, > > + AUDIT_NFT_OP_SET_UNREGISTER, > > + AUDIT_NFT_OP_SETELEM_REGISTER, > > + AUDIT_NFT_OP_SETELEM_UNREGISTER, > > + AUDIT_NFT_OP_GEN_REGISTER, > > + AUDIT_NFT_OP_OBJ_REGISTER, > > + AUDIT_NFT_OP_OBJ_UNREGISTER, > > + AUDIT_NFT_OP_OBJ_RESET, > > + AUDIT_NFT_OP_FLOWTABLE_REGISTER, > > + AUDIT_NFT_OP_FLOWTABLE_UNREGISTER, > > + AUDIT_NFT_OP_INVALID, > > +}; > > + > > +struct audit_nftcfgop_tab { > > + enum nf_tables_msg_types nftop; > > + enum audit_nfcfgop op; > > +}; > > + > > +static const struct audit_nftcfgop_tab audit_nftcfgs[] = { > > + { NFT_MSG_NEWTABLE, AUDIT_NFT_OP_TABLE_REGISTER }, > > + { NFT_MSG_GETTABLE, AUDIT_NFT_OP_INVALID }, > > + { NFT_MSG_DELTABLE, AUDIT_NFT_OP_TABLE_UNREGISTER }, > > + { NFT_MSG_NEWCHAIN, AUDIT_NFT_OP_CHAIN_REGISTER }, > > + { NFT_MSG_GETCHAIN, AUDIT_NFT_OP_INVALID }, > > + { NFT_MSG_DELCHAIN, AUDIT_NFT_OP_CHAIN_UNREGISTER }, > > + { NFT_MSG_NEWRULE, AUDIT_NFT_OP_RULE_REGISTER }, > > + { NFT_MSG_GETRULE, AUDIT_NFT_OP_INVALID }, > > + { NFT_MSG_DELRULE, AUDIT_NFT_OP_RULE_UNREGISTER }, > > + { NFT_MSG_NEWSET, AUDIT_NFT_OP_SET_REGISTER }, > > + { NFT_MSG_GETSET, AUDIT_NFT_OP_INVALID }, > > + { NFT_MSG_DELSET, AUDIT_NFT_OP_SET_UNREGISTER }, > > + { NFT_MSG_NEWSETELEM, AUDIT_NFT_OP_SETELEM_REGISTER }, > > + { NFT_MSG_GETSETELEM, AUDIT_NFT_OP_INVALID }, > > + { NFT_MSG_DELSETELEM, AUDIT_NFT_OP_SETELEM_UNREGISTER }, > > + { NFT_MSG_NEWGEN, AUDIT_NFT_OP_GEN_REGISTER }, > > + { NFT_MSG_GETGEN, AUDIT_NFT_OP_INVALID }, > > + { NFT_MSG_TRACE, AUDIT_NFT_OP_INVALID }, > > + { NFT_MSG_NEWOBJ, AUDIT_NFT_OP_OBJ_REGISTER }, > > + { NFT_MSG_GETOBJ, AUDIT_NFT_OP_INVALID }, > > + { NFT_MSG_DELOBJ, AUDIT_NFT_OP_OBJ_UNREGISTER }, > > + { NFT_MSG_GETOBJ_RESET, AUDIT_NFT_OP_OBJ_RESET }, > > + { NFT_MSG_NEWFLOWTABLE, AUDIT_NFT_OP_FLOWTABLE_REGISTER }, > > + { NFT_MSG_GETFLOWTABLE, AUDIT_NFT_OP_INVALID }, > > + { NFT_MSG_DELFLOWTABLE, AUDIT_NFT_OP_FLOWTABLE_UNREGISTER }, > > + { NFT_MSG_MAX, AUDIT_NFT_OP_INVALID }, > > }; > > I didn't check every "op" defined above to match with the changes in > nf_tables_api.c, but is there a reason why we can't simply hardcode > the AUDIT_NFT_OP_* values in the audit_log_nfcfg() calls in > nf_tables_api.c? If we can, let's do that. Yes, to distinguish between x/ebtables and nftables. The first three overlap (as suggested by the first comment in the changelog above). > If we can't do that, we need to add some build-time protection to > catch if NFT_MSG_MAX increases without this table being updated. I would have liked to do that, but it would then have meant making a new function name, say audit_log_nftcfg vs the original audit_log_nfcfg so that the overlapping values could be translated appropriately with the correct prefix. Well, considering the buildbot error, I had to restructure it so that the table was moved from include/linux/audit.h to net/netfilter/nf_tables_api.c where it would be a bit more evident. At first I thought the bot was complaining about the first field not being used, but it turned out it was ptrace that was including it and not using it. > > static int audit_match_perm(struct audit_context *ctx, int mask) > > 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. > > + kfree(buf); > > > > if (!ctx->report && > > !nfnetlink_has_listeners(ctx->net, NFNLGRP_NFTABLES)) > > 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