From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1089EC433E0 for ; Thu, 11 Feb 2021 17:32:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B439F64E87 for ; Thu, 11 Feb 2021 17:32:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231585AbhBKRc1 (ORCPT ); Thu, 11 Feb 2021 12:32:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37726 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231743AbhBKQaa (ORCPT ); Thu, 11 Feb 2021 11:30:30 -0500 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C3A75C061574 for ; Thu, 11 Feb 2021 08:29:46 -0800 (PST) Received: by mail-ej1-x62d.google.com with SMTP id f14so10968605ejc.8 for ; Thu, 11 Feb 2021 08:29:46 -0800 (PST) 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; bh=ABj8h6JxoKzCkEFlLOPlFl55Hb6x4ubH36UnScGj9KU=; b=BNxr53Eh4Rd+L3Iw+fOTZ3NITnYeHKeJ8+3HLB+AB44V4L2zuKgso8bfqhIZT85PdG MadFFUeEB8p8acfVuuXebGL5/coigQDu+Kkx9UYe62gOanXH4mBtMZG4A/EAZ7Dyr/6s KVRhrf9gIWH1e+4bBOu/eJkfQExosu4Xf7VL02HVcfadCSvcZGikKnqJhnp8bXf67oT1 +WkfOdhxc4ETMZs3Vgj+UIOMy8beZbbLvmViZBtOybjqxmPjhgU4hfHpL/ffyD1I9rkL yPqFnvkvqgJ4/bA6t+VSk0TaR7Mw6MV3oPTy16RPjBs2EjJaNHHJa+slCef/Ijb9pW98 qYiw== 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; bh=ABj8h6JxoKzCkEFlLOPlFl55Hb6x4ubH36UnScGj9KU=; b=FeLz71g9/9k8vp96mIkiPE2e+CeWAwfHSdbqkP0uog8+BLq9IdhYHaEUXcliwIoYdL 6aWaMQ5z9gnZLQiZP1lFqZ23DSQ8kpnkJ94fSaLlMl1ghu1lHNtHmcFNRqliTUBpgakG y5GB9p9ye1fEFUDlcZZnpP7kAFpt4ZOqeHxIsgwtPARkdtymy3k3mBEzRZlb6ACZAsV5 63g0/hILwFwxKwklwXioyGsRmTxBpIYVEs8xim54h6Q44ASpWylMD/kBOceLRcSEqGBw LoT3+bmiOf8to+UYVH21DytlwvFSvwlDKFe5vdMPMcGgIhNVj/HjIYsceSsE7uSMOBcM bghQ== X-Gm-Message-State: AOAM531q1B5w2UClDLP6M6SuDQl+/gSd8B/V2k4nqpcfUaKGCZtfEPVo cnIgInwP9ukjdeQSnDgOVIA07wlZChboA6PkqFo1 X-Google-Smtp-Source: ABdhPJweNZP4TzMhtMYaYgcn1PzXigwCB0MySFfbTC8o7Eq1L6ARWGPA1NXZPn9sU34dwjLDUP8/GMbabKeHGrzw3ck= X-Received: by 2002:a17:906:35d9:: with SMTP id p25mr9185445ejb.398.1613060985419; Thu, 11 Feb 2021 08:29:45 -0800 (PST) MIME-Version: 1.0 References: <20210211151606.GX3158@orbyte.nwl.cc> In-Reply-To: <20210211151606.GX3158@orbyte.nwl.cc> From: Paul Moore Date: Thu, 11 Feb 2021 11:29:34 -0500 Message-ID: Subject: Re: [PATCH ghak124 v3] audit: log nftables configuration change events To: Phil Sutter , Richard Guy Briggs , Linux-Audit Mailing List , LKML , netfilter-devel@vger.kernel.org, Paul Moore , sgrubb@redhat.com, Ondrej Mosnacek , fw@strlen.de, twoerner@redhat.com, Eric Paris , tgraf@infradead.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 11, 2021 at 10:16 AM Phil Sutter wrote: > Hi, > > On Thu, Jun 04, 2020 at 09:20:49AM -0400, 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. > > As discussed offline already, these audit notifications are pretty hefty > performance-wise. In an internal report, 300% restore time of a ruleset > containing 70k set elements is measured. If you're going to reference offline/off-list discussions in a post to a public list, perhaps the original discussion shouldn't have been off-list ;) If you don't involve us in the discussion, we have to waste a lot of time getting caught up. > If I'm not mistaken, iptables emits a single audit log per table, ipset > doesn't support audit at all. So I wonder how much audit logging is > required at all (for certification or whatever reason). How much > granularity is desired? That's a question for the people who track these certification requirements, which is thankfully not me at the moment. Unless somebody else wants to speak up, Steve Grubb is probably the only person who tracks that sort of stuff and comments here. I believe the netfilter auditing was mostly a nice-to-have bit of functionality to help add to the completeness of the audit logs, but I could very easily be mistaken. Richard put together those patches, he can probably provide the background/motivation for the effort. > I personally would notify once per transaction. This is easy and quick. > Once per table or chain should be acceptable, as well. At the very > least, we should not have to notify once per each element. This is the > last resort of fast ruleset adjustments. If we lose it, people are > better off with ipset IMHO. > > Unlike nft monitor, auditd is not designed to be disabled "at will". So > turning it off for performance-critical workloads is no option. Patches are always welcome, but it might be wise to get to the bottom of the certification requirements first. -- paul moore www.paul-moore.com From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 473DCC433E0 for ; Thu, 11 Feb 2021 16:30:25 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8C84D601FD for ; Thu, 11 Feb 2021 16:30:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8C84D601FD Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=paul-moore.com Authentication-Results: mail.kernel.org; spf=tempfail smtp.mailfrom=linux-audit-bounces@redhat.com 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-290-E4k8DRgRPiK3rvYc0FSRVw-1; Thu, 11 Feb 2021 11:30:20 -0500 X-MC-Unique: E4k8DRgRPiK3rvYc0FSRVw-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 92AD68030B7; Thu, 11 Feb 2021 16:30:17 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AF10D60936; Thu, 11 Feb 2021 16:30:16 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 4C1F24EE76; Thu, 11 Feb 2021 16:29:56 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 11BGTrM3026584 for ; Thu, 11 Feb 2021 11:29:53 -0500 Received: by smtp.corp.redhat.com (Postfix) id 87D3B2026D14; Thu, 11 Feb 2021 16:29:53 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast06.extmail.prod.ext.rdu2.redhat.com [10.11.55.22]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 82DE52026D13 for ; Thu, 11 Feb 2021 16:29:51 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0F88B185A793 for ; Thu, 11 Feb 2021 16:29:51 +0000 (UTC) Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com [209.85.218.54]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-551-KFsyAk7aMDiXuLHSVY283g-1; Thu, 11 Feb 2021 11:29:46 -0500 X-MC-Unique: KFsyAk7aMDiXuLHSVY283g-1 Received: by mail-ej1-f54.google.com with SMTP id l25so10968770eja.9 for ; Thu, 11 Feb 2021 08:29:46 -0800 (PST) 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; bh=ABj8h6JxoKzCkEFlLOPlFl55Hb6x4ubH36UnScGj9KU=; b=A72LIC647cF7gtJyCaBaQB92FF8e42gk5Kb5fl81RM5zvzjfQXoyG/eQDoSlJmBDwi tOCBnP7BTuLyvH0GYxnY3sPWUFJmf+pEtHfhujArnGzkK33zPYsQvlCUW+OeDIS3JVLW tSD7aAAmiuPlOjqOkJfuT+Tyf3nPslonDoW93lFrqMnCM5e6veHQrmp+ONOFgCcqeGVK N2qIpSnFgjNWGtzkx/8ulCa+hdV/iJOW0odsEK9Hob2ZMazjFsRd0RpXBJlJpjv61qp/ C7yMG9st4TtdzwcKgdhM8hN09jVGglzXpjA9h+QkY/SXf3A3nasWETNRPXai2mCk4PoU E31Q== X-Gm-Message-State: AOAM533l94XjBtjOGMbpNPFAK4G/RdiZ70RYw5QsNDpDpVyzVu3rjWSV NTRgxJFAA/p9fxgAWsWHHlgn7YNE5pThKEVYashG X-Google-Smtp-Source: ABdhPJweNZP4TzMhtMYaYgcn1PzXigwCB0MySFfbTC8o7Eq1L6ARWGPA1NXZPn9sU34dwjLDUP8/GMbabKeHGrzw3ck= X-Received: by 2002:a17:906:35d9:: with SMTP id p25mr9185445ejb.398.1613060985419; Thu, 11 Feb 2021 08:29:45 -0800 (PST) MIME-Version: 1.0 References: <20210211151606.GX3158@orbyte.nwl.cc> In-Reply-To: <20210211151606.GX3158@orbyte.nwl.cc> From: Paul Moore Date: Thu, 11 Feb 2021 11:29:34 -0500 Message-ID: Subject: Re: [PATCH ghak124 v3] audit: log nftables configuration change events To: Phil Sutter , Richard Guy Briggs , Linux-Audit Mailing List , LKML , netfilter-devel@vger.kernel.org, Paul Moore , sgrubb@redhat.com, Ondrej Mosnacek , fw@strlen.de, twoerner@redhat.com, Eric Paris , tgraf@infradead.org X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-loop: linux-audit@redhat.com X-BeenThere: linux-audit@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Linux Audit Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=linux-audit-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Thu, Feb 11, 2021 at 10:16 AM Phil Sutter wrote: > Hi, > > On Thu, Jun 04, 2020 at 09:20:49AM -0400, 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. > > As discussed offline already, these audit notifications are pretty hefty > performance-wise. In an internal report, 300% restore time of a ruleset > containing 70k set elements is measured. If you're going to reference offline/off-list discussions in a post to a public list, perhaps the original discussion shouldn't have been off-list ;) If you don't involve us in the discussion, we have to waste a lot of time getting caught up. > If I'm not mistaken, iptables emits a single audit log per table, ipset > doesn't support audit at all. So I wonder how much audit logging is > required at all (for certification or whatever reason). How much > granularity is desired? That's a question for the people who track these certification requirements, which is thankfully not me at the moment. Unless somebody else wants to speak up, Steve Grubb is probably the only person who tracks that sort of stuff and comments here. I believe the netfilter auditing was mostly a nice-to-have bit of functionality to help add to the completeness of the audit logs, but I could very easily be mistaken. Richard put together those patches, he can probably provide the background/motivation for the effort. > I personally would notify once per transaction. This is easy and quick. > Once per table or chain should be acceptable, as well. At the very > least, we should not have to notify once per each element. This is the > last resort of fast ruleset adjustments. If we lose it, people are > better off with ipset IMHO. > > Unlike nft monitor, auditd is not designed to be disabled "at will". So > turning it off for performance-critical workloads is no option. Patches are always welcome, but it might be wise to get to the bottom of the certification requirements first. -- paul moore www.paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit