-F dir=/nfs/path ?

[Peter Moody]

Did some digging and this is my understanding. Please correct me if
I'm grossly mistaken.

-F dir=foo is a tree rule, not a watch rule.

At syscall exit time, audit_filter_syscall is called which checks the
parameters of
the syscall against each of the installed rules.

When it gets to the dir rule, it checks to see if the 'tree'
associated with the given
task matches the 'associated' with the rule, basically walking up the
path from '/' to
the end to see if it matches the given rule tree.

There should be no extra nfs traffic, and there should be no blowing
up of inotify/fsnotify watch lists for something like this.

kernel callpath:
call __audit_syscall_exit arch/x86/kernel/entry_32|64.S
 __audit_free kernel/auditsc.c:1752
 audit_get_context kernel/auditsc.c:957
  audit_filter_syscall kernel/auditsc.c:877
   audit_filter_rules kernel/auditsc.c:603
    match_tree_refs kernel/auditsc.c:444
     audit_tree_match kernel/audit_tree.c:198

Does that sound right?

On Tue, Jun 26, 2012 at 11:01 AM, Peter Moody <pmoody at google.com> wrote:
> How does auditd perform on a rule like the following, assuming that
> /home/ is an nfs mount?
>
> -a exit,always -F arch=b64 -S open -F dir=/home/ -F a2&2 -F success=1
> -C euid!=obj_uid -k
>
> Does this become a watch rule (and to watch rules even work with nfs)?
> Assuming that the mount map for /home/ is giant (several K entries),
> does this run the risk of filling fsnotify (inotify?) watch lists?
>
> Cheers,
> peter
>
> --
> Peter Moody      Google    1.650.253.7306
> Security Engineer  pgp:0xC3410038



-- 
Peter Moody      Google    1.650.253.7306
Security Engineer  pgp:0xC3410038