All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Boyce, Kevin P (AS)" <Kevin.Boyce@ngc.com>
To: Florian Crouzat <gentoo@floriancrouzat.net>,
	Steve Grubb <sgrubb@redhat.com>
Cc: "linux-audit@redhat.com" <linux-audit@redhat.com>
Subject: RE: EXT :Re: PCI-DSS: Log every root actions/keystrokes  but avoid passwords
Date: Fri, 13 Jul 2012 17:09:15 +0000	[thread overview]
Message-ID: <5CB21FE316752445AF212D47C8BE561112EA2031@XMBVAG75.northgrum.com> (raw)
In-Reply-To: <500027B4.9040104@floriancrouzat.net>

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@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@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@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

  parent reply	other threads:[~2012-07-13 17:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-10  7:29 PCI-DSS: Log every root actions/keystrokes but avoid passwords Florian Crouzat
2012-07-12 19:41 ` Thugzclub
2012-07-13  8:14   ` Florian Crouzat
2012-07-13 13:27     ` Steve Grubb
2012-07-13 13:50       ` Florian Crouzat
2012-07-13 14:11         ` Valentin Avram
2012-07-13 17:09         ` Boyce, Kevin P (AS) [this message]
2012-07-16  8:05           ` EXT :Re: " Florian Crouzat
2012-07-16 13:20             ` Steve Grubb
2012-07-13 14:23 ` Miloslav Trmac

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5CB21FE316752445AF212D47C8BE561112EA2031@XMBVAG75.northgrum.com \
    --to=kevin.boyce@ngc.com \
    --cc=gentoo@floriancrouzat.net \
    --cc=linux-audit@redhat.com \
    --cc=sgrubb@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.