On Wednesday, June 27, 2012 09:14:04 AM Peter Moody wrote: > 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.
Correct. > 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? I'm not sure NFS is supported. I don't remember the reason as its been a long time. But if you have NFS for a home dir, then it should be easy to test. -Steve > On Tue, Jun 26, 2012 at 11:01 AM, Peter Moody <[email protected]> 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 -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
