From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Crouzat Subject: Re: PCI-DSS: Log every root actions/keystrokes but avoid passwords Date: Fri, 13 Jul 2012 15:50:44 +0200 Message-ID: <500027B4.9040104@floriancrouzat.net> References: <4FFBD9D6.2080902@floriancrouzat.net> <67597D99-9688-497A-9CE8-572B3E25E6FB@gmail.com> <4FFFD903.7020103@floriancrouzat.net> <6455125.Mmrnxe7ddi@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <6455125.Mmrnxe7ddi@x2> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: Thugzclub , linux-audit@redhat.com List-Id: linux-audit@redhat.com Le 13/07/2012 15:27, Steve Grubb a =E9crit : > Hmm...I thought I sent an answer. The problem from the kernel's perspecti= ve is > that it has no idea what user space is doing. It can't tell a password fr= om > 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