On Thursday, September 29, 2011 10:31:06 AM Worsham, Michael wrote: > type=CWD msg=audit(1316431049.130:131982948): cwd="/" > > type=PATH msg=audit(1316431049.130:131982948): item=0 > name="/usr/lib/vmware-tools/lib64/libdnet.so.1/tls/x86_64/libc.so.6" > > type=SYSCALL msg=audit(1316431049.130:131982949): arch=c000003e syscall=2 > success=no exit=-2 a0=7fffacb237a0 a1=0 a2=2abb06288000 > a3=6462696c2f343662 items=1 ppid=3921 pid=3923 auid=4294967295 uid=0 gid=0 > euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 > comm="sed" exe="/bin/sed" subj=system_u:system_r:initrc_t:s0 key=(null)
This is an open syscall failing with ENOENT. You do not get audit events like this by default. You have to have a rule that is triggering it. But which one? The results do not have a key value attached to the rule, so you will need to look at your rules that may catch failed opens. But this is really indicating a system problem. Why is a file missing? Does it need the file? Is there some configuration option that is wrong? Barring that, I would look at you rules that catch failed opens and ask if you really meant to catch ENOENT? If not, I would rewrite those rules. The example rules shipped with the audit package do not try to catch any failed open because glibc will look around for certain files that normally do not exist and you get a lot of ENOENT failures on any program startup. Instead, we only catch EPERM and EACCES failures because those are the security relevant failures for open. > Current rules: > ## Suppress all VMware Tools system calls > > -a exit,never -F arch=b32 -S fork -F success=0 -F > path=/usr/lib/vmware-tools -F subj_type=initrc_t -F exit=-ENOENT > > -a exit,never -F arch=b64 -S fork -F success=0 -F > path=/usr/lib/vmware-tools -F subj_type=initrc_t -F exit=-ENOENT -a > exit,never -F arch=b32 -S fork -F success=0 -F path=/usr/lib/vmware-tools > -F subj_type=initrc_t -F exit=-2 -a exit,never -F arch=b64 -S fork -F > success=0 -F path=/usr/lib/vmware-tools -F subj_type=initrc_t -F exit=-2 If you are intent on suppressing this rather than correcting the system setup or existing rules, then just make sure these rules load before your other open based syscall rules are loaded. Audit is first matching rule wins, so you want the suppression to match before the one that generates the event. -Steve -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
