Wouldn't another option be to audit the exec of particular executables you are
interested in knowing if someone runs?
Obviously you won't know what they are typing into text documents and such, but is
that really required? Most places don't allow key loggers at all and it sounds like
that's what you've got.
-----Original Message-----
From: linux-audit-bounces(a)redhat.com [mailto:linux-audit-bounces@redhat.com] On Behalf Of
Florian Crouzat
Sent: Friday, July 13, 2012 9:51 AM
To: Steve Grubb
Cc: Thugzclub; linux-audit(a)redhat.com
Subject: EXT :Re: PCI-DSS: Log every root actions/keystrokes but avoid passwords
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit