Re: PCI-DSS: Log every root actions/keystrokes but avoid passwords
On Wednesday, March 13, 2013 10:55:29 AM Richard Guy Briggs wrote:
On Tue, Mar 12, 2013 at 05:09:15PM -0400, Steve Grubb wrote:
> On Tuesday, March 12, 2013 04:47:42 PM Richard Guy Briggs wrote:
> > On Tue, Mar 12, 2013 at 07:06:59AM -0400, Miloslav Trmac wrote:
> > > ----- Original Message -----
> > >
> > > > I am resurrecting this old thread from last summer because I ran
> > > > into
> > > > the same issue and found the thread in the archives via Google. It
> > > > would be very nice if everything could be logged except passwords.
> > >
> > > There is work being done. Sorry, I don't have more specifics as to
> > > availability, perhaps others do.
> >
> > Hi Tracy,
> >
> > I'm actually working on that right now. I have a patch I am in the
> > process of testing. It implements a new sysctl.
>
> Why would this be done as a sysctl? Everything else in the audit system is
> configured through the netlink API. I would think that we would want to
> have it configured by the same pam module that we currently use to enable
> tty auditing. So, why not make a new netlink command that pam can use?
The lazy and naive answer is that that was the approach that was
suggested by two developers much more familiar with this code than me (I
expect that to balance out with time.)
Now that you suggest this, I agree that approach makes a lot of sense.
The more technical answer might be that it is much more expedient to do
it with a sysctl since it involves fewer compiled entities to implement
and hence can be rolled out faster with less co-ordination of other
software projects.
To me, its more important to not have a proliferation of places that must be
tweaked for the audit system. Its not a big deal to patch pam to have a new
argument.
After the kernel is recompiled (needed in any case)
it can be implemented with one line added to a file in /etc/sysctl.d/
while your approach requires adding code to audit and pam, waiting for
it to be released by their respective teams, then the user adding a
config option to the pam module invocation. I agree that would be more
convenient for end users since it can be an option added in the same
place as the module is invoked.
The problem that I have had for a long time is that there is no way to query
the kernel and ask what its audit capabilities are so that meaningful user
space warnings can be given.
I haven't seen a lot of requests for this feature yet, but it
sounds
like there could be a lot of interest, so it may be worth doing
correctly, rather than as a quick fix.
Am I missing anything?
Nope. Let's make it nice and easy to configure in the same place that its
already being done. :-)
Thanks,
-Steve