Why are audit events apparently non-attributable?
- From: dexterclarke@xxxxxxxxxxxxx
- Date: Sat, 29 Sep 2007 19:35:50 -0400
So I'm exploring AUDIT and have this in /etc/security/audit_control:
dir:/var/audit
flags:lo,fd
minfree:20
naflags:lo
policy:cnt
filesz:0
I tell auditd to reread the config file with audit -s but no file
deletion events are logged.
I change the config file to:
dir:/var/audit
flags:lo
minfree:20
naflags:lo,fd
policy:cnt
filesz:0
I type audit -s and am immediately flooded with 20 kilobytes worth
of audit records about file deletions.
What I don't understand is why these file deletions are non-attributable?
Surely if I sit there touching and removing files, the events should be
very cleary attributed to me? Even more strange is that the events look
like this:
header,130,10,unlink(2),0,Sat Sep 29 20:48:46 2007, + 957 msec
path,/var/tmp/vi.recover/vi.zhcey0
attribute,600,root,wheel,126,24774,98340
subject,-1,root,wheel,root,wheel,78355,0,0,0.0.0.0
return,success,0
trailer,130
To me, that looks like the event was attributed to 'root', so why does
it only appear when using 'naflags' ie. non attributable events?
Perhaps I misunderstand something fundamental.
--
dc
_______________________________________________
freebsd-security@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@xxxxxxxxxxx"
- Prev by Date: Why are most audit events apparently non-attributable?
- Previous by thread: Why are most audit events apparently non-attributable?
- Index(es):
Relevant Pages
|
|
