There is another way we used to pass PCI-DSS. We use an audit rule to log all EXECVE happening on production servers, rsyslog the logs to the remote centralized logs server, then parse the audit logs there using a cron script and rebuild the commands issued on each server by any user id. Hope this helps. <div class="gmail_quote">On Jul 13, 2012 4:53 PM, "Florian Crouzat" <<a href="mailto:gentoo@floriancrouzat.net">gentoo@floriancrouzat.net</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Le 13/07/2012 15:27, Steve Grubb a écrit : <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hmm...I thought I sent an answer. The problem from the kernel's perspective is that it has no idea what user space is doing. It can't tell a password from anything else being typed. There is a flag that can be set for the TTY to hide characters. But the issue then becomes that now you have a loophole that a crafty admin could use to hide what he's really doing. If anyone has ideas on how to improve this, I think we should. -Steve </blockquote> Yeah, I was afraid of that... At least, thanks for clarifying. I guess I'll stick with stating: don't fire any real root shell to all my sysadmins in the PCI-DSS scope. (as it's impossible to completely forbid all possible case , eg: forbid sudo -*, sudo sudo *, sudo su * but hell, you can't forbid sudo ./foo.sh where foo fires a shell, there is NOEXEC in sudo but then you can't do anything except reading...) Anyway, I'm getting away of the real matter, avoiding to audit-log passwords keystrokes. -- Cheers, Florian Crouzat -- Linux-audit mailing list <a href="mailto:Linux-audit@redhat.com" target="_blank">Linux-audit@redhat.com</a> <a href="https://www.redhat.com/mailman/listinfo/linux-audit" target="_blank">https://www.redhat.com/mailman/listinfo/linux-audit</a> </blockquote></div>