Seeking auditd help

Seeking auditd help

[Bill Jackson III]

[-- Attachment #1.1: Type: text/plain, Size: 178 bytes --]

Any pointers for troubleshooting  auditd missing events for file reads,
edits, etc. ( -w _path_ -p raw) on OEL5/RHEL 5/CentOS 5?

http://security.stackexchange.com/q/89009/56827

[-- Attachment #1.2: Type: text/html, Size: 289 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Seeking auditd help

[Steve Grubb]

On Monday, May 11, 2015 11:50:19 AM Bill Jackson III wrote:
> Any pointers for troubleshooting  auditd missing events for file reads,
> edits, etc. ( -w _path_ -p raw) on OEL5/RHEL 5/CentOS 5?
> 
> http://security.stackexchange.com/q/89009/56827

The -w notation is the same as

-a always,exit -F path=XXX -F perms=rwa

What this does is audit the following functions defined in the syscall 
classifiers
:
http://lxr.free-electrons.com/source/include/asm-generic/audit_read.h
http://lxr.free-electrons.com/source/include/asm-generic/audit_write.h
http://lxr.free-electrons.com/source/include/asm-generic/audit_change_attr.h

You are not going to get a hit for each and every read system call because 
read is not audited.

-Steve

Re: Seeking auditd help

[Burn Alting]

On Mon, 2015-05-11 at 15:52 -0400, Steve Grubb wrote:
> On Monday, May 11, 2015 11:50:19 AM Bill Jackson III wrote:
> > Any pointers for troubleshooting  auditd missing events for file reads,
> > edits, etc. ( -w _path_ -p raw) on OEL5/RHEL 5/CentOS 5?
> > 
> > http://security.stackexchange.com/q/89009/56827
> 
> The -w notation is the same as
> 
> -a always,exit -F path=XXX -F perms=rwa
> 
> What this does is audit the following functions defined in the syscall 
> classifiers
> :
> http://lxr.free-electrons.com/source/include/asm-generic/audit_read.h
> http://lxr.free-electrons.com/source/include/asm-generic/audit_write.h
> http://lxr.free-electrons.com/source/include/asm-generic/audit_change_attr.h
> 
> You are not going to get a hit for each and every read system call because 
> read is not audited.

Bill,

Is your question

  "Can one apply a file watch using auditd if the file does not exist?"

then I believe the answer is no. 

Options would be 
- as part of your application deployment standard operating procedures
(SOPs) add appropriate watches to audit.rules and restart the auditd
service
- keep all you sensitive files in one directory location, set a
directory watch on this directory tree and then as part of your
application deployment SOPs, place the real files in the sensitive file
area and then link to them from the application area. (I've just tried
this on a fc22 system and it works)

Regards

Re: Seeking auditd help

[Richard Guy Briggs]

On 15/05/12, Burn Alting wrote:
> On Mon, 2015-05-11 at 15:52 -0400, Steve Grubb wrote:
> > On Monday, May 11, 2015 11:50:19 AM Bill Jackson III wrote:
> > > Any pointers for troubleshooting  auditd missing events for file reads,
> > > edits, etc. ( -w _path_ -p raw) on OEL5/RHEL 5/CentOS 5?
> > > 
> > > http://security.stackexchange.com/q/89009/56827
> > 
> > The -w notation is the same as
> > 
> > -a always,exit -F path=XXX -F perms=rwa
> > 
> > What this does is audit the following functions defined in the syscall 
> > classifiers
> > :
> > http://lxr.free-electrons.com/source/include/asm-generic/audit_read.h
> > http://lxr.free-electrons.com/source/include/asm-generic/audit_write.h
> > http://lxr.free-electrons.com/source/include/asm-generic/audit_change_attr.h
> > 
> > You are not going to get a hit for each and every read system call because 
> > read is not audited.
> 
> Bill,
> 
> Is your question
> 
>   "Can one apply a file watch using auditd if the file does not exist?"
> 
> then I believe the answer is no. 

There is a patch set coming to be able to address this case if the
directory exists.  Down the road, I'm hoping to be able to accomodate
non-existant directories too.

> Options would be 
> - as part of your application deployment standard operating procedures
> (SOPs) add appropriate watches to audit.rules and restart the auditd
> service
> - keep all you sensitive files in one directory location, set a
> directory watch on this directory tree and then as part of your
> application deployment SOPs, place the real files in the sensitive file
> area and then link to them from the application area. (I've just tried
> this on a fc22 system and it works)
> 
> Regards

- RGB

--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545