2:21 p.m.
I'm running the sample CAPP rules with the .87 kernel and 1.0.1
audit tools. I'm seeing duplicate watch/inode messages sometimes.
The sample CAPP rules set a watch on all access to /etc/sysconfig
(-w /etc/sysconfig/). I created a file (ljk) in /etc/sysconfig and
when I update it (echo "1" > /etc/sysconfig/ljk) I get audit
records like below. Notice that the FS_WATCH and FS_INODE
lines show up twice. That doesn't seem right. Any ideas?
-- ljk
type=SYSCALL msg=audit(1123701552.619:2552): arch=c0000032 syscall=1028
success=yes exit=3 a0=600000000003bdf0 a1=241 a2=1b6 a3=2 items=1
pid=3711 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 comm="bash" exe="/bin/bash"
type=FS_WATCH msg=audit(1123701552.619:2552): watch_inode=554882
watch="sysconfig" filterkey= perm=0 perm_mask=1
type=FS_INODE msg=audit(1123701552.619:2552): inode=554882 inode_uid=0
inode_gid=0 inode_dev=08:13 inode_rdev=00:00
type=FS_WATCH msg=audit(1123701552.619:2552): watch_inode=554882
watch="sysconfig" filterkey= perm=0 perm_mask=1
type=FS_INODE msg=audit(1123701552.619:2552): inode=554882 inode_uid=0
inode_gid=0 inode_dev=08:13 inode_rdev=00:00
type=CWD msg=audit(1123701552.619:2552): cwd="/home/ljk"
type=PATH msg=audit(1123701552.619:2552): name="/etc/sysconfig/ljk"
flags=310 inode=554882 dev=08:13 mode=040755 ouid=0 ogid=0 rdev=00:00
3:14 p.m.
>I'm running the sample CAPP rules with the .87 kernel and
1.0.1
>audit tools. I'm seeing duplicate watch/inode messages sometimes.
Did this happen in previous kernels? .85 or .80 for example.
I just tried .77 and .81 (what I had handy on my system) and it does the
same on both of those.
-- ljk
4:50 p.m.
On Wednesday 10 August 2005 15:14, Linda Knippers wrote:
>>I'm running the sample CAPP rules with the .87 kernel and 1.0.1
>>audit tools. I'm seeing duplicate watch/inode messages sometimes.
>
> Did this happen in previous kernels? .85 or .80 for example.
I just tried .77 and .81 (what I had handy on my system) and it does the
same on both of those.
Hi,
I haven't been able to spend any time on this issue, but I don't necessarily
consider it a critical issue or anything that needs immediate attention. With
the new fswatch framework and auditfs piece the first half of this problem is
addressed and the second half does not [yet] exist.
What needs to happen and does happen in the new framework is that the
aux linked-list on the audit_context is walked and checked for the FS_INODE.
If it exists, the watch is added to that FS_INODE, otherwise a new FS_INODE
on the aux list and the watch is added to it. This effectively consolidates
all watches to one corresponding FS_INODE entry.
Now, the second half of the problem, reporting identical FS_WATCHes is non-
existant in the new audit framework currently due to the "fsnotify"-like
hooks. What we're seeing now is the same hook being hit multiple times in
the same code path because this system was designed around hook
consolidation. This might become a problem if we add an "fsnotify"-like hook
to critical functions like permission() which might be called multiple times
in the same code path (hooking this function might not even be needed
though). In the event that we do introduce the possibility of duplication,
the record should probably be discarded. This could be kind of expensive
having to first walk the aux list and then walk the FS_INODE's watch list
comparing fields.
-tim
-- ljk
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
4:57 p.m.
On Wednesday 10 August 2005 16:50, Timothy R. Chavez wrote:
On Wednesday 10 August 2005 15:14, Linda Knippers wrote:
>
> >>I'm running the sample CAPP rules with the .87 kernel and 1.0.1
> >>audit tools. I'm seeing duplicate watch/inode messages sometimes.
> >
> > Did this happen in previous kernels? .85 or .80 for example.
>
> I just tried .77 and .81 (what I had handy on my system) and it does the
> same on both of those.
Hi,
I haven't been able to spend any time on this issue, but I don't necessarily
consider it a critical issue or anything that needs immediate attention.
With
the new fswatch framework and auditfs piece the first half of this
problem
is
addressed and the second half does not [yet] exist.
What needs to happen and does happen in the new framework is that the
aux linked-list on the audit_context is walked and checked for the FS_INODE.
If it exists, the watch is added to that FS_INODE, otherwise a new FS_INODE
on the aux list and the watch is added to it. This effectively consolidates
all watches to one corresponding FS_INODE entry.
Now, the second half of the problem, reporting identical FS_WATCHes is non-
existant in the new audit framework currently due to the "fsnotify"-like
hooks.
I should definately correct myself... When I wrote "new audit framework" I
really meant the "new 'watchfs' framework". And my apologies on the
weird
pseudo run-on sentence :) *cough*
-tim
What we're seeing now is the same hook being hit multiple times
in
the same code path because this system was designed around hook
consolidation. This might become a problem if we add an "fsnotify"-like
hook
to critical functions like permission() which might be called
multiple times
in the same code path (hooking this function might not even be needed
though). In the event that we do introduce the possibility of duplication,
the record should probably be discarded. This could be kind of expensive
having to first walk the aux list and then walk the FS_INODE's watch list
comparing fields.
-tim
>
> -- ljk
>
> --
> Linux-audit mailing list
> Linux-audit(a)redhat.com
> http://www.redhat.com/mailman/listinfo/linux-audit
>
>
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
7074
days inactive
7074
days old
linux-audit@lists.linux-audit.osci.io
4 comments
3 participants
participants (3)
-
Linda Knippers -
Steve Grubb -
Timothy R. Chavez