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=-5.8 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 4BE1AC433ED for ; Tue, 6 Apr 2021 13:55:39 +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 E8F3961279 for ; Tue, 6 Apr 2021 13:55:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E8F3961279 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=tempfail smtp.mailfrom=linux-audit-bounces@redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1617717338; 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=Se4/NukFX86tWCJ8eeIFhiNculdDps3bN05rqb68OPU=; b=hK/TVeoe3hghNrpavuS9IC2K0UN8Z4TTCa3CCE+rAuaN4G4dxIWzUrW1H5Tse8W2d/HME3 JYqAa2Su2XPMzkNjwH9YuCQBKIfIoUMgz1AJEVKQbMJzAVnd9au79NgA19vQCDruvEBXAw NvtCGo5YoNyGciAzztidsDPl3qcNUoA= 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-375-_acc2bpXPT2fNR2jv9T9tA-1; Tue, 06 Apr 2021 09:55:36 -0400 X-MC-Unique: _acc2bpXPT2fNR2jv9T9tA-1 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 mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0281D8189DD; Tue, 6 Apr 2021 13:55:32 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8F46D5C890; Tue, 6 Apr 2021 13:55:31 +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 5FB2F1809C83; Tue, 6 Apr 2021 13:55:30 +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 136DtSS3011456 for ; Tue, 6 Apr 2021 09:55:28 -0400 Received: by smtp.corp.redhat.com (Postfix) id 45E4F60937; Tue, 6 Apr 2021 13:55:28 +0000 (UTC) Received: from x2.localnet (ovpn-116-9.rdu2.redhat.com [10.10.116.9]) by smtp.corp.redhat.com (Postfix) with ESMTP id EF68560854; Tue, 6 Apr 2021 13:55:27 +0000 (UTC) From: Steve Grubb To: Linux-Audit Mailing List Subject: Re: Grouping audit events in an auditd log parser Date: Tue, 06 Apr 2021 09:55:24 -0400 Message-ID: <1780427.tdWV9SEqCh@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.16 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 Tuesday, April 6, 2021 9:03:50 AM EDT Alan Evangelista wrote: > Hi! I was using auditbeat to connect to the audit kernel module and get > filesystem operations events from it. However, as I discussed in another > thread, it seems that the audit events kernel queue is buggy in kernel 3.1, > the kernel version available on CentOS 7. This means that if > auditbeat crashes for any reason, I'll start losing FS events. In order to > make my event detection more resilient, I decided to move the critical > point of failure from auditbeat to auditd: I'll let auditd write a log file > and write a fluentd parser to read from that log file. > > Writing that auditd log parser, I reached a question: how to group audit > records in a FS event (for instance, there are SYSCALL, CWD and PATHs audit > events for a single file creation, deletion or renaming). Can I assume > that *all* records of an event will always appear sequentially in the log > file with the same timestamp/event ID or records from different filesystem > operations can be interleaved? Ex: simultaneous fsop 1 and fsop 2 could > show up like: > > TYPE:SYSCALL msg=audit(167111.123:1) (...) > TYPE:CWD msg=audit(167111.123:1) (...) > TYPE:SYSCALL msg=audit(167112.123:2) (...) > TYPE:PATH msg=audit(167111.123:1) (...) > TYPE:PATH msg=audit(167111.123:1) (...) > TYPE:CWD msg=audit(167112.123:1) (...) > TYPE:PATH msg=audit(167112.123:1) (...) > > ? Nope. You cannot assume that. Serialization is left as an exercise for user space. Also, there is an audit parsing library that knows how to group events and hides all additional complexity. You can either use it to parse the log directly or to get the events from the realtime interface. -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit