Re: PCI-DSS: Log every root actions/keystrokes but avoid passwords

Steve Grubb
2013-03-13T15:59:07Z

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