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=-6.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 3422AC8302B for ; Thu, 2 Sep 2021 16:30:57 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E83D461A0C for ; Thu, 2 Sep 2021 16:21:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org E83D461A0C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=tempfail smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1630599708; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=LwfPRmm+xCXRCxxIf5zmy8pCTUunquy+cgeVSIzNfqU=; b=Ouhgy+PxqUcXMoWCSnwMLJ/koKkzHjbcn9amigq1SjAysth57bXWI5SB13g84TUUuS5xiA 6h4qna1mIvfBHoxSo6k/ikqxpeXE6KuyrmoRONtye53sE7/cr+R6GyZGeaqoInFxGmEZpZ 22ByJ2P+F24O3Qaak0xBsGQBcCa+640= 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-577-eWDivL0tPbqxedNb9iWgGg-1; Thu, 02 Sep 2021 12:21:46 -0400 X-MC-Unique: eWDivL0tPbqxedNb9iWgGg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E20E2189C446; Thu, 2 Sep 2021 16:21:37 +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 828A469CAD; Thu, 2 Sep 2021 16:21:37 +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 EF7D144A5A; Thu, 2 Sep 2021 16:21:36 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 182GLZ46018704 for ; Thu, 2 Sep 2021 12:21:35 -0400 Received: by smtp.corp.redhat.com (Postfix) id D98D383BEB; Thu, 2 Sep 2021 16:21:35 +0000 (UTC) Received: from x2.localnet (unknown [10.22.17.46]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8D54C83BE4; Thu, 2 Sep 2021 16:21:27 +0000 (UTC) From: Steve Grubb To: linux-audit@redhat.com Subject: Re: audit.rules being really processed sequentially? Date: Thu, 02 Sep 2021 12:21:27 -0400 Message-ID: <3130208.aeNJFYEL58@x2> Organization: Red Hat In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 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.11 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 Thursday, September 2, 2021 11:54:12 AM EDT Ede Wolf wrote: > In my pursuit of taming auditd in that it only logs what has explicitly > been defined and nothing more, I've thought of a set of catch all rules > at the end. As the rules file is supposedly being processed > sequentially, i.e. first hit matches, this ought to work. But it doesn't. > > Having a very simple rules file as an example: > > -D > -e 1 > > -a exit,always -F arch=b64 -S execve -F path=/bin/vi -k EDIT_FILE > > -a always,exclude -F msgtype=EXECVE > -a always,exclude -F msgtype=FD_PAIR > -a always,exclude -F msgtype=FS_RELABEL > ... > > (continue this for every messagetype from this link: > > https://access.redhat.com/articles/4409591#audit-record-types-2) > > As easily to be guessed, my expectation would be, the invokation of vi > by anyone would get logged, as that rules comes first, but really > nothing else, as it is being discaded by the catchall rules. > > Surprisingly however, in reality, nothing gets logged at all, not even > the invocation of vi. > > Now, removing those catchall rules at the end does log the calling of > vi, but of course also all other stuff I neither have defined nor want > to be written out. > > So, if the audit.rules file really is being processed sequentally, what > am I missing in my approach? It might be useful to look at slide 15 of this: http://people.redhat.com/sgrubb/audit/audit_ids_2011.pdf The output of the rule matching engine gets fed to the exclude filter for a second look. The exclude filter then drops objectionable records. In your case, it its told to drop everything. Audit records in the 1300 block are related to rules. You need to let all of them through. -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit