Re: sudo false negative in audit trails
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