Path ignored but syscall event still logged

Discussion:

Max Williams

2011-12-20 17:55:49 UTC

Hi All,
I have a system that is logging many events for a path that I think should be ignored...

[***@host1 ~]# auditctl -l
LIST_RULES: exit,always dir=/etc/audit (0xa) perm=wa key=auditd_configuration
LIST_RULES: exit,always dir=/etc/audisp (0xb) perm=wa key=auditd_configuration
LIST_RULES: exit,always watch=/etc/libaudit.conf perm=wa key=auditd_configuration
LIST_RULES: exit,always watch=/etc/sysconfig/auditd perm=wa key=auditd_configuration
LIST_RULES: exit,never dir=/etc/lvm/cache (0xe) syscall=all
LIST_RULES: exit,never dir=/opt (0x4) syscall=all
LIST_RULES: exit,never dir=/tmp (0x4) syscall=all
LIST_RULES: exit,never dir=/naab1 (0x6) syscall=all
LIST_RULES: exit,never dir=/naab2 (0x6) syscall=all
LIST_RULES: exit,never dir=/ab1 (0x4) syscall=all
LIST_RULES: exit,never dir=/ab2 (0x4) syscall=all
LIST_RULES: exit,always perm=a key=file_attributes
LIST_RULES: exit,always arch=3221225534 (0xc000003e) a1=1074292226 (0x40086602) key=file_attributes syscall=ioctl
LIST_RULES: exit,always arch=3221225534 (0xc000003e) a1=-2146933247 (0x80086601) key=file_attributes syscall=ioctl
LIST_RULES: exit,always arch=3221225534 (0xc000003e) exit=-13 (0xfffffff3) key=invalid_logical_access syscall=open
LIST_RULES: exit,always dir=/bin (0x4) perm=wa key=bin_modification
LIST_RULES: exit,always dir=/boot (0x5) perm=wa key=boot_modification
LIST_RULES: exit,always dir=/etc (0x4) perm=wa key=etc_modification
LIST_RULES: exit,always dir=/home (0x5) perm=wa key=home_modification
LIST_RULES: exit,always dir=/lib (0x4) perm=wa key=lib_modification
LIST_RULES: exit,always dir=/lib64 (0x6) perm=wa key=lib64_modification
LIST_RULES: exit,always dir=/root (0x5) perm=wa key=root_modification
LIST_RULES: exit,always dir=/sbin (0x5) perm=wa key=sbin_modification
LIST_RULES: exit,always dir=/usr (0x4) perm=wa key=usr_modification
LIST_RULES: exit,always dir=/var/spool/at (0xd) perm=wa key=misc_var
LIST_RULES: exit,always dir=/var/spool/cron (0xf) perm=wa key=misc_var
LIST_RULES: exit,never dir=/var (0x4) syscall=all
LIST_RULES: exit,always arch=3221225534 (0xc000003e) key=dir_operations syscall=mkdir,rmdir,unlinkat
LIST_RULES: exit,always arch=3221225534 (0xc000003e) key=link_operation syscall=rename,link,unlink,symlink
LIST_RULES: exit,always arch=3221225534 (0xc000003e) key=special_device_creation syscall=mknod,mknodat
LIST_RULES: exit,always arch=3221225534 (0xc000003e) key=mount_operation syscall=mount,umount2
LIST_RULES: exit,always arch=3221225534 (0xc000003e) key=kernel_module syscall=create_module,init_module,delete_module
LIST_RULES: exclude,always msgtype=CRED_ACQ (0x44f)
LIST_RULES: exclude,always msgtype=CRED_DISP (0x450)
LIST_RULES: exclude,always msgtype=CRYPTO_KEY_USER (0x964)
LIST_RULES: exclude,always msgtype=CRYPTO_SESSION (0x967)
LIST_RULES: exclude,always msgtype=LOGIN (0x3ee)
LIST_RULES: exclude,always msgtype=USER_ACCT (0x44d)
LIST_RULES: exclude,always msgtype=USER_AUTH (0x44c)
LIST_RULES: exclude,always msgtype=USER_CMD (0x463)
LIST_RULES: exclude,always msgtype=USER_END (0x452)
LIST_RULES: exclude,always msgtype=USER_LOGIN (0x458)
LIST_RULES: exclude,always msgtype=USER_START (0x451)
[***@host1 ~]# tail /var/log/audit/audit.log
node=host1.domain type=PATH msg=audit(1324401918.113:223550509): item=3 name="checkpoint.1568280a-4eef7e3f-38e9.102.138" inode=30958573 dev=fd:0d mode=0100660 ouid=3534 ogid=9001 rdev=00:00
node=host1.domain type=PATH msg=audit(1324401918.113:223550510): item=2 name="temp_checkpoint.checkpoint.1568280a-4eef7e3f-38d2.76.138" inode=30958636 dev=fd:0d mode=0100660 ouid=3534 ogid=9001 rdev=00:00
node=host1.domain type=PATH msg=audit(1324401918.113:223550510): item=3 name="checkpoint.1568280a-4eef7e3f-38d2.76.138" inode=30958614 dev=fd:0d mode=0100660 ouid=3534 ogid=9001 rdev=00:00
node=host1.domain type=PATH msg=audit(1324401918.113:223550509): item=4 name="checkpoint.1568280a-4eef7e3f-38e9.102.138" inode=30958644 dev=fd:0d mode=0100660 ouid=3534 ogid=9001 rdev=00:00
node=host1.domain type=PATH msg=audit(1324401918.113:223550510): item=4 name="checkpoint.1568280a-4eef7e3f-38d2.76.138" inode=30958636 dev=fd:0d mode=0100660 ouid=3534 ogid=9001 rdev=00:00
node=host1.domain type=SYSCALL msg=audit(1324401918.113:223550511): arch=c000003e syscall=82 success=yes exit=0 a0=7ecdb0 a1=7d10e0 a2=7f6c0782dcd4 a3=0 items=4 ppid=14614 pid=16951 auid=7463 uid=3534 gid=9001 euid=3534 suid=3534 fsuid=3534 egid=9001 sgid=9001 fsgid=9001 tty=(none) ses=9372 comm="db-update.impl." exe="/var/some-app/some-app-V3-0-3/gcc4p64/db_v2/bin/db-update.impl.gcc4p64" key="link_operation"
node=host1.domain type=SYSCALL msg=audit(1324401918.113:223550512): arch=c000003e syscall=82 success=yes exit=0 a0=9a6e50 a1=92e9f0 a2=7fe84e682cd4 a3=0 items=4 ppid=14595 pid=14937 auid=7463 uid=3534 gid=9001 euid=3534 suid=3534 fsuid=3534 egid=9001 sgid=9001 fsgid=9001 tty=(none) ses=10226 comm="multitool.impl." exe="/var/some-app/some-app-V3-0-3/gcc4p64/bin/multitool" key="link_operation"
node=host1.domain type=CWD msg=audit(1324401918.113:223550511): cwd="/naab1/serial/data/dir1/serial/dir2/abc_load/temp/some-app/.WORK-serial/1568280a-4eef7e3f-3873"
node=host1.domain type=CWD msg=audit(1324401918.113:223550512): cwd="/naab1/serial/data/dir1/serial/dir2/abc_load/temp/some-app/.WORK-serial/1568280a-4ef0423c-38fe"
node=host1.domain type=PATH msg=audit(1324401918.113:223550511): item=0 name="/naab1/serial/data/dir1/serial/dir2/abc_load/temp/some-app/.WORK-serial/1568280a-4eef7e3f-3873" inode=30932995 dev=fd:0d mode=040755 ouid=3534 ogid=9001 rdev=00:00
[***@host1 ~]#

I'm referring to event ID 223550511 (key is link_operation) in the logs which is using a path of '/naab1/...'

How come this event is not ignored due to the 8th rule? I think I'm missing something.

Many thanks,
Max

________________________________________________________________________
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.

________________________________________________________________________

Steve Grubb

2011-12-20 19:02:43 UTC

Permalink

Post by Max Williams
How come this event is not ignored due to the 8th rule? I think I'm missing something.

One piece of information is missing. The enforcement of the audit policy is done
by the kernel. What do you get for uname -r?

-Steve

Max Williams

2011-12-21 12:17:01 UTC

Permalink

Sorry, forgot to include that!

[***@host1 ~]# uname -r
2.6.32-131.21.1.el6.x86_64
[***@host1 ~]# auditctl -s
AUDIT_STATUS: enabled=1 flag=0 pid=24173 rate_limit=0 backlog_limit=8192 lost=124822501 backlog=0

It's a RHEL6.1 server.
Cheers,
Max

-----Original Message-----
From: Steve Grubb [mailto:***@redhat.com]
Sent: 20 December 2011 19:03
To: linux-***@redhat.com
Cc: Max Williams
Subject: Re: Path ignored but syscall event still logged

Post by Max Williams
How come this event is not ignored due to the 8th rule? I think I'm missing something.

One piece of information is missing. The enforcement of the audit policy is done by the kernel. What do you get for uname -r?

-Steve

________________________________________________________________________
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.

________________________________________________________________________

Steve Grubb

2011-12-21 19:24:45 UTC

Permalink

Post by Max Williams
Sorry, forgot to include that!
2.6.32-131.21.1.el6.x86_64
AUDIT_STATUS: enabled=1 flag=0 pid=24173 rate_limit=0 backlog_limit=8192
lost=124822501 backlog=0

Initial assessment, the kernel patch that discards events might only work on
open(2). Eric is looking to see if this can be safely broadened.

-Steve

Post by Max Williams

Post by Max Williams
How come this event is not ignored due to the 8th rule? I think I'm missing something.

One piece of information is missing. The enforcement of the audit policy is
done by the kernel. What do you get for uname -r?
-Steve

Max Williams

2012-01-06 17:26:17 UTC

Permalink

Any update on this Steve? The other ignore rules seem to work, just not that one.
Thanks,
Max

-----Original Message-----
From: Steve Grubb [mailto:***@redhat.com]
Sent: 21 December 2011 19:25
To: linux-***@redhat.com
Cc: Max Williams
Subject: Re: Path ignored but syscall event still logged

Post by Max Williams
Sorry, forgot to include that!
2.6.32-131.21.1.el6.x86_64
AUDIT_STATUS: enabled=1 flag=0 pid=24173 rate_limit=0
backlog_limit=8192
lost=124822501 backlog=0

Initial assessment, the kernel patch that discards events might only work on open(2). Eric is looking to see if this can be safely broadened.

-Steve

Post by Max Williams

Post by Max Williams
How come this event is not ignored due to the 8th rule? I think I'm missing something.

One piece of information is missing. The enforcement of the audit
policy is done by the kernel. What do you get for uname -r?
-Steve

Max Williams

2012-01-12 14:45:59 UTC

Permalink

Hi All,
Sorry to bug you but is this issue I'm having a bug or have I made a mistake in the rules? Is there another way I could exclude this directory from auditd?
We have licenses for these servers so I could open a case if need be.
Many thanks,
Max

-----Original Message-----
From: linux-audit-***@redhat.com [mailto:linux-audit-***@redhat.com] On Behalf Of Max Williams
Sent: 06 January 2012 17:26
To: linux-***@redhat.com
Subject: RE: Path ignored but syscall event still logged

Any update on this Steve? The other ignore rules seem to work, just not that one.
Thanks,
Max

-----Original Message-----
From: Steve Grubb [mailto:***@redhat.com]
Sent: 21 December 2011 19:25
To: linux-***@redhat.com
Cc: Max Williams
Subject: Re: Path ignored but syscall event still logged

Post by Max Williams
Sorry, forgot to include that!
2.6.32-131.21.1.el6.x86_64
AUDIT_STATUS: enabled=1 flag=0 pid=24173 rate_limit=0
backlog_limit=8192
lost=124822501 backlog=0

Initial assessment, the kernel patch that discards events might only work on open(2). Eric is looking to see if this can be safely broadened.

-Steve

Post by Max Williams

Post by Max Williams
How come this event is not ignored due to the 8th rule? I think I'm missing something.

One piece of information is missing. The enforcement of the audit
policy is done by the kernel. What do you get for uname -r?
-Steve

________________________________________________________________________
In order to protect our email recipients, Betfair Group use SkyScan from MessageLabs to scan all Incoming and Outgoing mail for viruses.

________________________________________________________________________

--
Linux-audit mailing list
Linux-***@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

________________________________________________________________________
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.

________________________________________________________________________

Steve Grubb

2012-01-12 15:04:22 UTC

Permalink

Post by Max Williams
Sorry to bug you but is this issue I'm having a bug or have I made a
mistake in the rules? Is there another way I could exclude this directory
from auditd? We have licenses for these servers so I could open a case if
need be.

The preliminary investigation was its a kernel bug. It needs to be checked in
more detail to see what the fix is.

-Steve

Max Williams

2012-01-12 15:07:24 UTC

Permalink

OK, thanks for clarifying Steve. I'll open a support case with RH.
Cheers,
Max

-----Original Message-----
From: Steve Grubb [mailto:***@redhat.com]
Sent: 12 January 2012 15:04
To: linux-***@redhat.com
Cc: Max Williams
Subject: Re: Path ignored but syscall event still logged

Post by Max Williams
Sorry to bug you but is this issue I'm having a bug or have I made a
mistake in the rules? Is there another way I could exclude this
directory from auditd? We have licenses for these servers so I could
open a case if need be.

The preliminary investigation was its a kernel bug. It needs to be checked in more detail to see what the fix is.

-Steve

________________________________________________________________________
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.

________________________________________________________________________

Steve Grubb

2012-01-13 14:45:32 UTC

Permalink

Post by Max Williams
Sorry to bug you but is this issue I'm having a bug or have I made a
mistake in the rules? Is there another way I could exclude this directory
from auditd?

Max Williams

2012-01-13 16:46:58 UTC

Permalink

Hi Steve,
Thanks for the reply. Yes and yes:

[***@host1 ~]# mount|grep ab
/dev/mapper/VolGroupCF00-abf_graph on /naab2 type ext4 (rw)
/dev/mapper/VolGroupCF01-abf_icff on /naab1 type ext4 (rw)

[***@host1 ~]# ll /|grep ab
lrwxrwxrwx 1 root root 6 May 9 2011 ab1 -> /naab1
lrwxrwxrwx 1 root root 6 May 9 2011 ab2 -> /naab2
drwxrwx--- 5 root ab_users 4096 May 20 2011 naab1
drwxrwx--- 6 root ab_users 4096 Jun 29 2011 naab2
[***@host1 ~]#

How does that affect the the rule, which was for the actual mount point, not the sym link?
LIST_RULES: exit,never dir=/naab1 (0x6) syscall=all

Cheers,
Max

-----Original Message-----
From: Steve Grubb [mailto:***@redhat.com]
Sent: 13 January 2012 14:46
To: linux-***@redhat.com
Cc: Max Williams
Subject: Re: Path ignored but syscall event still logged

Post by Max Williams
Sorry to bug you but is this issue I'm having a bug or have I made a
mistake in the rules? Is there another way I could exclude this
directory from auditd?

Looking back at the original...

/naab1/serial/data/dir1/serial/dir2/abc_load/temp/some-app/.WORK-
serial/1568280a-4eef7e3f-3873

Are there any mount points in that path? Or any symlinks pointing to other disk devices?

Thanks,
-Steve

________________________________________________________________________
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.

________________________________________________________________________

Steve Grubb

2012-01-13 18:51:45 UTC

Permalink

Post by Max Williams
Hi Steve,
/dev/mapper/VolGroupCF00-abf_graph on /naab2 type ext4 (rw)
/dev/mapper/VolGroupCF01-abf_icff on /naab1 type ext4 (rw)
lrwxrwxrwx 1 root root 6 May 9 2011 ab1 -> /naab1
lrwxrwxrwx 1 root root 6 May 9 2011 ab2 -> /naab2
drwxrwx--- 5 root ab_users 4096 May 20 2011 naab1
drwxrwx--- 6 root ab_users 4096 Jun 29 2011 naab2
How does that affect the the rule, which was for the actual mount point,
not the sym link? LIST_RULES: exit,never dir=/naab1 (0x6) syscall=all

Its OK for the top level dir to be a mount point. However, what about
everything under it?

/naab1/serial/data/dir1/serial/dir2/abc_load/temp/some-app/.WORK-serial/1568280a-4eef7e3f-3873

Could data or dir1 be a mount point? If anything under /naab1 is
a mount point, then you have to tell the kernel to treat it as equivalent
to the parent dir that you have the rule on. For example, suppose data
was in fact a moint point and you mounted /dev/sda1 onto it. You
would need to add the follwoing to your audit rules:

-q /naab1/serial/data,/dev/sda1

As for symlinks, I'm not sure that a recursive watch will follow the
symlink. If for example, some-app was a symlink to /opt/some-app,
I am pretty sure the watch will not follow over to the other device.
You would have to add a watch on /opt/some-app to get events.

The same thing applies for suppressing events.

-Steve

Post by Max Williams
-----Original Message-----
Sent: 13 January 2012 14:46
Cc: Max Williams
Subject: Re: Path ignored but syscall event still logged

Post by Max Williams
Sorry to bug you but is this issue I'm having a bug or have I made a
mistake in the rules? Is there another way I could exclude this
directory from auditd?

Looking back at the original...
/naab1/serial/data/dir1/serial/dir2/abc_load/temp/some-app/.WORK-
serial/1568280a-4eef7e3f-3873
Are there any mount points in that path? Or any symlinks pointing to other disk devices?
Thanks,
-Steve
________________________________________________________________________
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.
________________________________________________________________________
--
Linux-audit mailing list
https://www.redhat.com/mailman/listinfo/linux-audit

Max Williams

2012-01-16 11:13:35 UTC

Permalink

Hi Steve,

There are no mount points anywhere in that path apart from at the top level. I'm 99% sure there were no sym links either but that path has since been removed so I can't be completely sure.

To make things a bit simpler I can reproduce it with a much shorter path and definitely no sym links within the path:

[***@hostb001 ~]# auditctl -l

LIST_RULES: exit,always dir=/etc/audit (0xa) perm=wa key=auditd_configuration

LIST_RULES: exit,always dir=/etc/audisp (0xb) perm=wa key=auditd_configuration

LIST_RULES: exit,always watch=/etc/libaudit.conf perm=wa key=auditd_configuration

LIST_RULES: exit,always watch=/etc/sysconfig/auditd perm=wa key=auditd_configuration

LIST_RULES: exit,never dir=/etc/lvm/cache (0xe) syscall=all

LIST_RULES: exit,never dir=/opt (0x4) syscall=all

LIST_RULES: exit,never dir=/tmp (0x4) syscall=all

LIST_RULES: exit,never dir=/naab1 (0x6) syscall=all

LIST_RULES: exit,never dir=/naab2 (0x6) syscall=all

LIST_RULES: exit,never dir=/ab1 (0x4) syscall=all

LIST_RULES: exit,never dir=/ab2 (0x4) syscall=all

LIST_RULES: exit,never dir=/usr/openv/netbackup (0x14) syscall=all

LIST_RULES: exit,always perm=a key=file_attributes

LIST_RULES: exit,always arch=3221225534 (0xc000003e) a1=1074292226 (0x40086602) key=file_attributes syscall=ioctl

LIST_RULES: exit,always arch=3221225534 (0xc000003e) a1=-2146933247 (0x80086601) key=file_attributes syscall=ioctl

LIST_RULES: exit,always arch=3221225534 (0xc000003e) exit=-13 (0xfffffff3) key=invalid_logical_access syscall=open

LIST_RULES: exit,always dir=/bin (0x4) perm=wa key=bin_modification

LIST_RULES: exit,always dir=/boot (0x5) perm=wa key=boot_modification

LIST_RULES: exit,always dir=/etc (0x4) perm=wa key=etc_modification

LIST_RULES: exit,always dir=/home (0x5) perm=wa key=home_modification

LIST_RULES: exit,always dir=/lib (0x4) perm=wa key=lib_modification

LIST_RULES: exit,always dir=/lib64 (0x6) perm=wa key=lib64_modification

LIST_RULES: exit,always dir=/root (0x5) perm=wa key=root_modification

LIST_RULES: exit,always dir=/sbin (0x5) perm=wa key=sbin_modification

LIST_RULES: exit,always dir=/usr (0x4) perm=wa key=usr_modification

LIST_RULES: exit,always dir=/var/spool/at (0xd) perm=wa key=misc_var

LIST_RULES: exit,always dir=/var/spool/cron (0xf) perm=wa key=misc_var

LIST_RULES: exit,never dir=/var (0x4) syscall=all

LIST_RULES: exit,always arch=3221225534 (0xc000003e) key=dir_operations syscall=mkdir,rmdir,unlinkat

LIST_RULES: exit,always arch=3221225534 (0xc000003e) key=link_operation syscall=rename,link,unlink,symlink

LIST_RULES: exit,always arch=3221225534 (0xc000003e) key=special_device_creation syscall=mknod,mknodat

LIST_RULES: exit,always arch=3221225534 (0xc000003e) key=mount_operation syscall=mount,umount2

LIST_RULES: exit,always arch=3221225534 (0xc000003e) key=kernel_module syscall=create_module,init_module,delete_module

LIST_RULES: exclude,always msgtype=CRED_ACQ (0x44f)

LIST_RULES: exclude,always msgtype=CRED_DISP (0x450)

LIST_RULES: exclude,always msgtype=CRYPTO_KEY_USER (0x964)

LIST_RULES: exclude,always msgtype=CRYPTO_SESSION (0x967)

LIST_RULES: exclude,always msgtype=LOGIN (0x3ee)

LIST_RULES: exclude,always msgtype=USER_ACCT (0x44d)

LIST_RULES: exclude,always msgtype=USER_AUTH (0x44c)

LIST_RULES: exclude,always msgtype=USER_CMD (0x463)

LIST_RULES: exclude,always msgtype=USER_END (0x452)

LIST_RULES: exclude,always msgtype=USER_LOGIN (0x458)

LIST_RULES: exclude,always msgtype=USER_START (0x451)

[***@hostb001 ~]#

[***@hostb001 ~]# mount|grep naab1

/dev/mapper/VolGroupB01-abb_landing on /naab1 type ext4 (rw)

[***@hostb001 ~]#

[***@hostb001 ~]# ls -l /|grep naab1

lrwxrwxrwx 1 root root 6 Jun 6 2011 ab1 -> /naab1

drwxr-x--- 6 app app_users 4096 Aug 23 13:23 naab1

[***@hostb001 ~]#

[***@hostb001 ~]# touch /naab1/temp-file

[***@hostb001 ~]# chmod 600 /naab1/temp-file

[***@hostb001 ~]#

[***@hostb001 ~]# tail -3 /var/log/audit/audit.log

node=hostb001.domain type=SYSCALL msg=audit(1326711394.421:3737872): arch=c000003e syscall=268 success=yes exit=0 a0=ffffffffffffff9c a1=60d1d0 a2=180 a3=0 items=1 ppid=20688 pid=32510 auid=7382 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=49941 comm="chmod" exe="/bin/chmod" key="file_attributes"

node=hostb001.domain type=CWD msg=audit(1326711394.421:3737872): cwd="/root"

node=hostb001.domain type=PATH msg=audit(1326711394.421:3737872): item=0 name="/naab1/temp-file" inode=12 dev=fd:0d mode=0100600 ouid=0 ogid=0 rdev=00:00

[***@hostb001 ~]#

Does this make it a bit clearer? I look forward to your reply.

Many thanks,

Max

-----Original Message-----
From: Steve Grubb [mailto:***@redhat.com]
Sent: 13 January 2012 18:52
To: linux-***@redhat.com
Cc: Max Williams
Subject: Re: Path ignored but syscall event still logged

Post by Max Williams
Hi Steve,
/dev/mapper/VolGroupCF00-abf_graph on /naab2 type ext4 (rw)
/dev/mapper/VolGroupCF01-abf_icff on /naab1 type ext4 (rw)
lrwxrwxrwx 1 root root 6 May 9 2011 ab1 -> /naab1
lrwxrwxrwx 1 root root 6 May 9 2011 ab2 -> /naab2
drwxrwx--- 5 root ab_users 4096 May 20 2011 naab1
drwxrwx--- 6 root ab_users 4096 Jun 29 2011 naab2
How does that affect the the rule, which was for the actual mount
point, not the sym link? LIST_RULES: exit,never dir=/naab1 (0x6)
syscall=all

Its OK for the top level dir to be a mount point. However, what about everything under it?

/naab1/serial/data/dir1/serial/dir2/abc_load/temp/some-app/.WORK-serial/1568280a-4eef7e3f-3873

Could data or dir1 be a mount point? If anything under /naab1 is a mount point, then you have to tell the kernel to treat it as equivalent to the parent dir that you have the rule on. For example, suppose data was in fact a moint point and you mounted /dev/sda1 onto it. You would need to add the follwoing to your audit rules:

-q /naab1/serial/data,/dev/sda1

As for symlinks, I'm not sure that a recursive watch will follow the symlink. If for example, some-app was a symlink to /opt/some-app, I am pretty sure the watch will not follow over to the other device.

You would have to add a watch on /opt/some-app to get events.

The same thing applies for suppressing events.

-Steve

Post by Max Williams
-----Original Message-----
Sent: 13 January 2012 14:46
Cc: Max Williams
Subject: Re: Path ignored but syscall event still logged

Post by Max Williams
Sorry to bug you but is this issue I'm having a bug or have I made a
mistake in the rules? Is there another way I could exclude this
directory from auditd?

Looking back at the original...
/naab1/serial/data/dir1/serial/dir2/abc_load/temp/some-app/.WORK-
serial/1568280a-4eef7e3f-3873
Are there any mount points in that path? Or any symlinks pointing to
other disk devices?
Thanks,
-Steve
______________________________________________________________________
__ In order to protect our email recipients, Betfair Group use SkyScan
from MessageLabs to scan all Incoming and Outgoing mail for viruses.
______________________________________________________________________
__
--
Linux-audit mailing list
https://www.redhat.com/mailman/listinfo/linux-audit