From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Weird issues in 2.6.5 Date: Wed, 13 Jul 2016 12:42:22 -0400 Message-ID: <4163033.HK5e6qXJ5d@x2> References: <1592387.yc9HYPXd4B@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1592387.yc9HYPXd4B@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: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Wednesday, July 13, 2016 12:32:55 PM EDT Steve Grubb wrote: > On Wednesday, July 13, 2016 9:22:57 AM EDT Chris Nandor wrote: > > Secondary question: the reason for what I'm working on is that we want to > > be able to audit what folks do as root on our production hosts. We're not > > a bank, and a perfect solution is not required, but we do need to be able > > to take reasonable steps to find out if people with access are doing bad > > things. > > > > Is this setup reasonable for that purpose? > > Yes. You would want to do two things, first enable tty auditing. This is > done by the pam_tty_audit module. Second consider adding the > 32-power-abuse.rules to your rules. > > > I know that's a loaded question > > and I can answer any questions anyone has that are necessary to figure > > this > > out. I am not asking so much about rules, but about architecture: logging > > according to whatever rules we set up, to the local audit.log and > > immediately to a remote using audisp-remote, so the log can't be easily > > manipulated. > > Remote logging is the defence against local log manipulation. Another thing to consider is that the 2.6 version of the audit user space has a new logging format. You might consider going into auditd.conf and setting log_format = enriched. This resolves some information locally before sending it to the remote system. -Steve