From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: sudo false negative in audit trails Date: Wed, 19 Sep 2007 11:12:50 -0400 Message-ID: <200709191112.50479.sgrubb@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com Cc: "Todd, Charles" List-Id: linux-audit@redhat.com On Wednesday 19 September 2007 10:24:04 Todd, Charles wrote: > I'm chasing down a false negative I'm getting in my ausearch output > which makes it look like successful sudo access results in a failed > CRED_ACQ record. Is anyone else seeing this? I'm going to list out my > system specs, but please actually look at a sudo run in your system (if > similar) before writing off my non-standard pieces: > - RHEL4u4 (2.6.9.-42.0.2) > - audit-1.0.15 > - quest-sudo-1.6.8p12q76 > - pam 0.77-66.17 > > Command: > # ausearch -m CRED_ACQ |grep sudo |tail -1 > type=CRED_ACQ msg=audit(1190207432.508:168552): user pid=13971 uid=0 > auid=1110 msg='PAM setcred: user=root exe="/opt/quest/bin/sudo" > (hostname=?, addr=?, terminal=pts/1 result=Permission denied)' This is not a false negative. This is pam telling you that something in the auth section failed. It may be configured to be ignored by pam, but it really did fail. > They're all like that. Remember - the sudo actually granted me access > as requested. > > /etc/pam.d/sudo looks like this, as generated by quest-sudo: > auth [ignore=ignore success=done default=die] pam_vas3.so create_homedir ^^^ this is the likely guilty party. > account [ignore=ignore success=done default=die] pam_vas3.so > password [ignore=ignore success=done default=die] pam_vas3.so > session [ignore=ignore success=done default=die] pam_vas3.so > create_homedir > > I've reviewed the base sudo package source code and could find no > changelog entries to the part that tells PAM whether or not success was > made. I'd review how it handles failed calls to pam_setcred and whether the module properly supports pam_sm_setcred function. > I know that sudo has to tell PAM who tells auditd whether or not > VAS authenticated the user. Sudo works just find though - it's only the > auditing which is squirelly. pam does it all. The question really is the pam module working right? > As for PAM, well, 0.77 is very old, But very well audited for bugs. :) -Steve