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.4 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 3913BC07E96 for ; Thu, 8 Jul 2021 19:27:11 +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 C8C9861621 for ; Thu, 8 Jul 2021 19:27:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C8C9861621 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=1625772429; 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=uuQY+AMbGNIpV/GtDH+4goU1akqrIEpQeim5FfESneo=; b=FeXu2QnQExFi3nLFGBQDMx/BgYmRtCE3/MuQlAjyYh7GvuLlByfXEybfJUsjfYP6ObUKYf 6NCdO1CBf51H/qkygtx9CHNehLN+xJrXX2SD5htEiSohJyKpurpOdd/e8AkAHRPwmV1+DZ 67gHbUrxdJ8ZUjCbkPKYJnSfwMYOSBg= 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-143-Eum1-w5bPqeD5Im9PZ1biw-1; Thu, 08 Jul 2021 15:27:06 -0400 X-MC-Unique: Eum1-w5bPqeD5Im9PZ1biw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B98BF1936B66; Thu, 8 Jul 2021 19:27:02 +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 20522100EB3E; Thu, 8 Jul 2021 19:27:02 +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 256B14EA29; Thu, 8 Jul 2021 19:27:01 +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 168JO5a0007463 for ; Thu, 8 Jul 2021 15:24:05 -0400 Received: by smtp.corp.redhat.com (Postfix) id 61FAB100EB3E; Thu, 8 Jul 2021 19:24:05 +0000 (UTC) Received: from x2.localnet (ovpn-117-206.rdu2.redhat.com [10.10.117.206]) by smtp.corp.redhat.com (Postfix) with ESMTP id EC6771017CE8; Thu, 8 Jul 2021 19:24:01 +0000 (UTC) From: Steve Grubb To: "Linux-audit@redhat.com" , linux-audit@redhat.com Subject: Re: The format of password change audit events seems to have changed, Can you confirm the correct record type ? Date: Thu, 08 Jul 2021 15:23:57 -0400 Message-ID: <2069430.irdbgypaU6@x2> Organization: Red Hat In-Reply-To: <0a5e0f1b52c5454cb7f31cb27ead857a@APLEX10.dom1.jhuapl.edu> References: <0a5e0f1b52c5454cb7f31cb27ead857a@APLEX10.dom1.jhuapl.edu> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 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.84 on 10.5.11.22 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, July 8, 2021 2:19:54 PM EDT Wieprecht, Karen M. wrote: > I've noticed that the messages I'm searching for in splunk to show root > password changes no longer seem to be in the same format. Most of our > systems run RHEL7 release 7.9, and I believe this is a recent change > (I've only noticed this problem in the past 3 months or so?), but we do > have an older 7.5 system, so I was able to use that to compare against > the 7.5 to identify what's changed. I wanted to confirm which record I > should be using now since there are several that get generated now > > The key differences seem to be in the message generated and the keyname > being used for the account being targeted, but I wanted to confirm that > there isn't some other record I should be looking at to verify that the > root password was changed in the required timeframe since I see several > records being generated from a password change, none of which include > anything as conclusive as the old message that showed the operation as a > "password change". Here are some fo the fields I'm looking at: > > type=USER_CHAUTHOK > exe=/usr/bin/passwd > [acct targeted for the passwd change]: > id=root (old format) > acct=root (latest format) > msg > msg='op=change password (old format) > msg='op=PAM:chauthok (latest format) > > If you can confirm whether this is the info I should be using now to > confirm password changes, that would be much appreciated. I don't have a RHEL 7.9 machine to compare against. I can set one up in about a week. On 7.6 the event looks like this: type=USER_CHAUTHTOK msg=audit(1625771196.574:162): pid=5113 uid=0 auid=1000 ses=1 subj=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 msg='op=change password id=1000 exe="/usr/bin/passwd" hostname=rhel7.3 addr=? terminal=pts/0 res=success' The problem is that "op= change passwd" has a space in it and will not parse right. I have been trying to correct instances of this so that things parse correctly. Not everyone runs their changes by me for comment. So, its possible that the change was made to fix the space, but usually I suggest people add an underscore. I'll into it more next week. -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit