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 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 03275C433EF for ; Mon, 10 Jan 2022 21:18:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1641849479; 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=P6rm04Wz7VFZgAqMKRi/RwOThX63N6P44j62R5xVjhw=; b=ZNBLCh/iA+sO9BjD+wI8z1NnMcpGSHgEuNByhuqbBDc6IktsMa7cWYe/df+4YIdxFCsKHq /PoyTKK4XH7EGraBU57rZrDyQ/pxgm6h4GoX34ePaKuX5xbhoC5XE+3JQccsMY9g9E4l2e x7Uhz2TqAnftJTattn8cno/gLL8wxkw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-325-oDJ8OQZvMT2c5UYjibRf_g-1; Mon, 10 Jan 2022 16:17:58 -0500 X-MC-Unique: oDJ8OQZvMT2c5UYjibRf_g-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 211371023F4E; Mon, 10 Jan 2022 21:17:52 +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 794F75DF3A; Mon, 10 Jan 2022 21:17:51 +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 6A4431809CB8; Mon, 10 Jan 2022 21:17:50 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 20ALHmPH014083 for ; Mon, 10 Jan 2022 16:17:48 -0500 Received: by smtp.corp.redhat.com (Postfix) id A0D5368D92; Mon, 10 Jan 2022 21:17:48 +0000 (UTC) Received: from x2.localnet (unknown [10.22.10.130]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4CC806AB85; Mon, 10 Jan 2022 21:17:45 +0000 (UTC) From: Steve Grubb To: linux-audit@redhat.com Subject: Re: Mapping of Audit rule to Record Type Generated + chmod log query Date: Mon, 10 Jan 2022 16:17:44 -0500 Message-ID: <5958705.lOV4Wx5bFT@x2> Organization: Red Hat In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-loop: linux-audit@redhat.com Cc: Rohit 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.14 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 Hello, On Monday, January 10, 2022 3:32:55 PM EST Rohit wrote: > Question 1 > I'm not even sure if this is feasible but does there exist an audit rule > type <--> record type mapping? Nope. > For example, a file watch rule for writes and attribute changes (-p wa) > would generate record types of SYSCALL and CWD. While a watch for execution > (-p x) on a file would generate a SYSCALL, EXECVE and CWD. > > Similarly, is there a way to know what record types the different audit > rule types (file watches, syscalls) may generate? There are 2 kinds of events, simple and compound. The simple events are typically standalone such as something originating from user space. The compound events always have a syscall event, but as to the auxiliary records, it really depends on the path the syscall takes through the kernel. Various places are hooked and collect information. When the syscall exits, then it dumps all the collected auxiliary records., > ----- > > Question 2 > I am trying to decipher a chmod related log entry. My audit rule is > -w /etc/passwd -p wa -k passwd_mod > > I thereafter ran a "chmod 744 /etc/passwd" . I received a SYSCALL record > type with the following parameters > type=SYSCALL msg=audit(1641846347.980:1326): arch=c000003e syscall=268 > success=yes exit=0 a0=ffffffffffffff9c a1=1a600f0 a2=1a4 a3=3c0 items=1 > ppid=6639 pid=6781 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 tty=pts6 ses=4294967295 comm="chmod" exe="/bin/chmod" > > I'm trying to decipher whether the above event can give me the exact > permission passed to the chmod command (755). I understand that execve may > give it to me easier. If you use ausearch -i to look at the raw record, it's much easier. type=SYSCALL msg=audit(01/10/2022 15:25:47.980:1326) : arch=x86_64 syscall=fchmodat success=yes exit=0 a0=AT_FDCWD a1=0x1a600f0 a2=0644 a3=0x3c0 items=1 ppid=6639 pid=6781 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts6 ses=unset comm=chmod exe=/ bin/chmod > I see the underlying syscall is fchmodat which accepts 3 arguments > > int dfd, const char __user *filename, umode_t mode > > In which case, in the above log event, would a3=3c0 be the right argument > to represent the new permission (755)? Or am I reading this incorrectly? The a2 argument is the one that has the mode. Ausearch shows that it's value is 0644. -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit