sudo false negative in audit trails

sudo false negative in audit trails

[Todd, Charles]

[-- Attachment #1.1: Type: text/plain, Size: 3051 bytes --]

Greetings,
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)'
 
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
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
 
For those unfamiliar with Quest's VAS (Vintella Authentication System),
it's basically a commercialized, polished winbindd from Samba 3.  They
have open-sourced their changes to the base package (good citizens) as
they are basically kerberizing some of the tools.  Sudo was modified to
support treating Active Directory roles as Unix groups (e.g.
DOMAIN\Administrators can run shells, but no one else).  
 
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 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.
 
Original sudo page that interacts with PAM:
http://www.sudo.ws/cgi-bin/cvsweb/sudo/auth/pam.c?rev=1.43&content-type=
text/x-cvsweb-markup&only_with_tag=SUDO_1_6_8p1
 
Quests modifications to the same file:
http://rc.quest.com/viewvc/sudo/tags/sudo-1.6.8p12q76/auth/pam.c?revisio
n=77&view=markup
 
So, I'm not so sure it's in sudo, but perhaps some bug between PAM and
sudo that I don't understand.  Can anyone else replicate this?
 
As for PAM, well, 0.77 is very old, but it's the newest that RedHat has
integrated.  RedHat has not posted any PAM changes related to sudo since
my package above.  At least RHEL5 is using 0.99.
 
Thanks for your time,
Charlie Todd 
Ball Aerospace & Technologies Corp.  

 



This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

[-- Attachment #1.2: Type: text/html, Size: 6603 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: sudo false negative in audit trails

[Steve Grubb]

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