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. On Jul 13, 2012 4:53 PM, "Florian Crouzat" <gen...@floriancrouzat.net> wrote: > Le 13/07/2012 15:27, Steve Grubb a écrit : > > 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 >> > > 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 > Linux-audit@redhat.com > https://www.redhat.com/**mailman/listinfo/linux-audit<https://www.redhat.com/mailman/listinfo/linux-audit> >
-- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit