audit (OpenBSM) & cat

[Robert Watson]

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