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

Richard Guy Briggs
2013-03-13T14:55:29Z

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. 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.

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?

> > I'm working in the upstream kernel, so it will likely be available in Linus'
> > git tree before anywhere else.
>
> Normally audit patches are sent to this mail list for review. If there are no
> objections then it can be pulled into an upstream tree.

I'll post this patch anyways.

> -Steve
>
> > After that, likely fedora, then RHEL, but I'm a bit new to that process.
> >
> > I don't see a reason why I couldn't post that patch here when I've got
> > it ironed out.

- RGB

--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer
AMER ENG Base Operating Systems
Remote, Canada, Ottawa
Voice: 1.647.777.2635
Internal: (81) 32635