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=-10.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 F1840C4361B for ; Fri, 18 Dec 2020 13:47:52 +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-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7F1E423A9C for ; Fri, 18 Dec 2020 13:47:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7F1E423A9C 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=1608299271; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc: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=kz84cQq4P4kwN5XOwSlaihxRYNZ33pGX9NERJQnfBkM=; b=IPMHrAZ280MpFKI7cCFsoTqF4KaTLE+wuRQIPL+mHy4gzoG9mmP5P4G+GN7rYQBzskT7FJ w6ckkZV0K9Er+eraqq4T1qTVU9t4yTkCNz8HOLoKkfXagRt+wH+FJfQrv3bQDvskVZT1aX YFkimF3+h2uM7vGCeUnBDG74UbtVrJ0= 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-55-rnZtRLXBPc-bTbOx0dUi2g-1; Fri, 18 Dec 2020 08:47:47 -0500 X-MC-Unique: rnZtRLXBPc-bTbOx0dUi2g-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7EA33100C615; Fri, 18 Dec 2020 13:47:43 +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 2D7889473; Fri, 18 Dec 2020 13:47:43 +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 C8241180954D; Fri, 18 Dec 2020 13:47:41 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 0BIDiUpg002063 for ; Fri, 18 Dec 2020 08:44:30 -0500 Received: by smtp.corp.redhat.com (Postfix) id 6DE3E10023B7; Fri, 18 Dec 2020 13:44:30 +0000 (UTC) Received: from x2.localnet (ovpn-114-141.rdu2.redhat.com [10.10.114.141]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8DE0D100239A; Fri, 18 Dec 2020 13:44:26 +0000 (UTC) From: Steve Grubb To: Andreas Hasenack Subject: Re: "key=" on all related log lines Date: Fri, 18 Dec 2020 08:44:24 -0500 Message-ID: <4613628.31r3eYUQgx@x2> Organization: Red Hat In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-loop: linux-audit@redhat.com Cc: 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.84 on 10.5.11.23 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 Friday, December 18, 2020 8:24:04 AM EST Andreas Hasenack wrote: > I use the -k "sometext" parameter in my audit rules, to help analyze > the logs. I noticed that it's only added to one of the log lines, not > the others, but the tools (ausearch, aureport) find the other related > entries nevertheless. Correct. > For example: > > -w /etc/shadow -p wa -k shadow-file-changed > > After a "# touch /etc/shadow" I get: > type=SYSCALL msg=audit(1608297571.005:160): arch=c000003e syscall=257 > success=yes exit=3 a0=ffffff9c a1=7ffedcecb865 a2=941 a3=1b6 items=2 > ppid=1623 pid=2382 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=pts1 ses=1 comm="touch" exe="/bin/touch" > key="shadow-file-changed" > type=CWD msg=audit(1608297571.005:160): cwd="/root" > type=PATH msg=audit(1608297571.005:160): item=0 name="/etc/" inode=206 > dev=fc:01 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=PARENT > cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 > type=PATH msg=audit(1608297571.005:160): item=1 name="/etc/shadow" > inode=64013 dev=fc:01 mode=0100640 ouid=0 ogid=42 rdev=00:00 > nametype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 > cap_fe=0 cap_fver=0 > type=PROCTITLE msg=audit(1608297571.005:160): > proctitle=746F756368002F6574632F736861646F77 > > But only the first line has my key. Correct. > Are the other entries correlated via the id in "audit(id)"? They are correlated by the combination of seconds since 1970, millisecond, and serial number. And the records between two events can be interlaced in the logs. Nothing in the klernel serializes the output. So, its entirely on user space to correlate things. > Is there a way to have the key parameter attached to all of them? No. > I'd like to send to a remote log server only certain events, and if I filter > by key, I only get one of these log lines. Then, I'd say you're not doing it the way it was intended. A simple grep is not sufficient. You would want to use the audit tools or auparse library to do this for you. They take care of the correlation and de-interlacing of events. And they can do the filtering. A good example is the setroubleshooter plugin. It filters just for AVC's and then sees if they have configuration solutions to avoid the AVC's. Writing a filre using the auparse library is pretty simple. You can find an example to start from here: https://github.com/linux-audit/audit-userspace/blob/master/contrib/plugin/ audisp-example.c I'd also suggest making any plugin double threaded, with one side dequeuing events and the other thread processing them and some kind of queue in between. If the socket buffer between auditd and the plugin gets full, it can affect the audit daemon's performance. -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit