From owner-freebsd-audit@FreeBSD.ORG Thu Mar 6 13:36:48 2008 Return-Path: Delivered-To: freebsd-audit@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 887F2106566B; Thu, 6 Mar 2008 13:36:48 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 429168FC28; Thu, 6 Mar 2008 13:36:48 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 62D7646B55; Thu, 6 Mar 2008 08:36:47 -0500 (EST) Date: Thu, 6 Mar 2008 13:36:47 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: sam In-Reply-To: <47AC2D71.1010405@gmail.com> Message-ID: <20080306133154.J21773@fledge.watson.org> References: <46C55191.2050205@gmail.com> <20070821145603.L50579@fledge.watson.org> <46CAF217.7040204@gmail.com> <20070821151108.Y53914@fledge.watson.org> <46CAF4E9.2030700@gmail.com> <20070821152327.R53914@fledge.watson.org> <46CBE096.90805@gmail.com> <20070828175313.B90180@fledge.watson.org> <47AC2D71.1010405@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: trustedbsd-audit@FreeBSD.org, freebsd-audit@freebsd.org Subject: Re: audit (OpenBSM) & cat X-BeenThere: freebsd-audit@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD Security Audit List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2008 13:36:48 -0000 On Fri, 8 Feb 2008, sam wrote: > description of trouble situation on system FreeBSD 6.3-RELEASE i386: > > open 2 putty console on remote server > > console1: # cat /dev/auditpipe | praudit -l > > console2: # cat >> /var/log/audit_cat.data > > console1 (output message): # cat /dev/auditpipe | praudit -l > header,168,10,open(2) - write,creat,0,Fri Feb 8 12:59:34 2008, + 309 > msec,argument,3,0x1b6,mode,argument,2,0x209,flags,path,/var/log/audit_cat.data,attribute,644,root,admin,72,2732063,10952279,subject,venom,root,wheel,root,wheel,44255,41955,1647,192.168.1.26,return,success,4,trailer,168, > > after 30 seconds > > console2 (cat waiting user input & user typing message & pusshing 'Ctrl+d' > for deattach ): # cat >> /var/log/audit_cat.data abracadabra_message # > > console1 (don`t output message on user action 'adding string > "abracadabra_message" & deattach'): # cat /dev/auditpipe | praudit -l > header,168,10,open(2) - write,creat,0,Fri Feb 8 12:59:34 2008, + 309 > msec,argument,3,0x1b6,mode,argument,2,0x209,flags,path,/var/log/audit_cat.data,attribute,644,root,admin,72,2732063,10952279,subject,venom,root,wheel,root,wheel,44255,41955,1647,192.168.1.26,return,success,4,trailer,168, > > > /dev/auditpipe output data on moment create file descriptor, but don`t > output message after adding string in file and close file > > any solution? Vladimir, I appear to have missed this e-mail when it came through about a month ago, sorry about that. By default /dev/auditpipe reports whatever is configured to go to the system audit trail for the user. So the real question, I think, is whether what's in /etc/security/{audit_control,audit_user} matches what you're seeing. Be aware that, in our default audit_events file, we don't make AUE_READ/AUE_READV/etc to any event class, so if you want to capture the actual I/O operations, you'll need to add it to a class and make sure that class is set for the users of interest. AUE_CLOSE, on the other hand, is mapped to the "cl" class by default, so if you've enabled auditing of "cl", you should see close events. WARNING: If you add auditing of individual read/write/send/receive I/O operations, you make it very, very easy to get audit event cycles. Make sure that any process that will be monitoring the audit event stream (for example, praudit /dev/auditpipe) is *not* seeing auditing of its reads and writes, or you may see a feedback effects. This is similar to running tcpdump from an ssh session -- each packet sent leads to yet more packets being sent, etc. We do support auditing those events, but the protection profiles of interest require auditing intent to read or write (open flags) rather than the actual operations in most cases. Robert N M Watson Computer Laboratory University of Cambridge