10:41 a.m.
I'm uploading the audit.19 kernel. It has Tim's latest patch and my
patch to log signals sent to the audit dæmon.
--
dwmw2
3:08 p.m.
On Wednesday 06 April 2005 11:41, David Woodhouse wrote:
I'm uploading the audit.19 kernel. It has Tim's latest patch
and my
patch to log signals sent to the audit dæmon.
I don't see any messages from the kernel saying a signal was being sent to the
audit daemon. Can you double check it? If you generate a new kernel, can you
include the backlog patch from yesterday?
audit.log:
type=DAEMON msg=auditd(1112904280) auditd start, ver=0.7, format=raw,
pid=2813, uid=0
type=KERNEL msg=audit(1112904280.748:0): audit_enabled=1 old=1 by auid 525
type=KERNEL msg=audit(1112904280.952:0): audit_backlog_limit=1024 old=1024 by
auid 525
type=DAEMON msg=auditd(1112904286) auditd normal halt, pid=2813, uid=0
messages:
Apr 7 16:04:40 localhost auditd[2813]: Init complete, audit pid set to: 2813
Apr 7 16:04:46 localhost auditd[2813]: The audit daemon is exiting.
Apr 7 16:04:46 localhost kernel: audit(1112904286.869:0): audit_pid=0
old=2813 by auid 525
uname:
[root@endeavor ~]# uname -a
Linux endeavor 2.6.9-5.0.3.EL.audit.19 #1 Wed Apr 6 09:10:02 EDT 2005 i686
athlon i386 GNU/Linux
-Steve
3:56 p.m.
On Thu, 2005-04-07 at 16:08 -0400, Steve Grubb wrote:
I don't see any messages from the kernel saying a signal was
being sent to the
audit daemon. Can you double check it? If you generate a new kernel, can you
include the backlog patch from yesterday?
fish /fish/pkgs/openoffice.org/devel # tail -2 /var/log/audit.log
type=DAEMON msg=auditd(1112872753) auditd normal halt, pid=10941, uid=0
type=KERNEL msg=audit(1112872753.335:0): attempt to signal audit daemon: error=0 signal=15
pid=10956 auid=-1
--
dwmw2
4:46 p.m.
On Thursday 07 April 2005 16:56, David Woodhouse wrote:
> I don't see any messages from the kernel saying a signal was
being sent
> to the audit daemon. Can you double check it? If you generate a new
> kernel, can you include the backlog patch from yesterday?
fish /fish/pkgs/openoffice.org/devel # tail -2 /var/log/audit.log
type=DAEMON msg=auditd(1112872753) auditd normal halt, pid=10941, uid=0
type=KERNEL msg=audit(1112872753.335:0): attempt to signal audit daemon:
error=0 signal=15 pid=10956 auid=-1
I'm not seeing the above message and I'm running your latest 686 kernel. Can
anyone else confirm seeing the message and what rpm arch they are using?
-Steve
10:03 a.m.
linux-audit-bounces(a)redhat.com wrote on 04/06/2005 10:41:06 AM:
I'm uploading the audit.19 kernel. It has Tim's latest patch
and my
patch to log signals sent to the audit dæmon.
--
dwmw2
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
I am seeing an inconsistent behavior when testing the watches with this
kernel. Is anybody else encountering something similar?
Below you will find the manual steps I am performing, and they only
generate two records (for the first touch, and the remove).
I also tried to set permissions to "reaw" to ensure I get all records, but
that didn't help either.
[root@checkered objident]# uname -a
Linux checkered.ltc.austin.ibm.com 2.6.9-5.0.3.EL.audit.19 #1 Wed Apr 6
09:10:02 EDT 2005 i686 i686 i386 GNU/Linux
[root@checkered objident]# rpm -qa | grep audit
audit-libs-0.6.10-1
audit-0.6.10-1
kernel-2.6.9-5.0.3.EL.audit.19
audit-libs-devel-0.6.10-1
[root@checkered lib]# auditctl -w /tmp/test_file -k file-key
No rules
[root@checkered lib]# touch /tmp/test_file
[root@checkered lib]# cat /tmp/test_file
[root@checkered lib]# cp /tmp/test_file /tmp/something
[root@checkered lib]# touch /tmp/test_file
[root@checkered lib]# cp /tmp/something /tmp/test_file
cp: overwrite `/tmp/test_file'? y
[root@checkered lib]# rm /tmp/test_file
rm: remove regular empty file `/tmp/test_file'? y
type=KERNEL msg=audit(1112950099.362:0): audit_enabled=1 old=1 by auid
4294967295
type=KERNEL msg=audit(1112950147.072:4062817): item=0
name="/tmp/test_file" inode=2223873 dev=fd:00 mode=041777 uid=0 gid=0
rdev=00:00
type=KERNEL msg=audit(1112950147.072:4062817): auxitem=1 name="test_file"
filterkey=file-key perm=0 perm_mask=2 inode=2224460 inode_uid=0
inode_gid=0 inode_dev=fd:00 inode_rdev=00:00
type=KERNEL msg=audit(1112950147.072:4062817): syscall=5 arch=40000003
success=yes exit=3 a0=bff7cbb2 a1=8941 a2=1b6 a3=8941 items=1 pid=4538
loginuid=-1 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
comm="touch" exe=/bin/touch
type=KERNEL msg=audit(1112950218.048:4070039): item=0
name="/tmp/test_file" inode=2223873 dev=fd:00 mode=041777 uid=0 gid=0
rdev=00:00
type=KERNEL msg=audit(1112950218.048:4070039): auxitem=1 name="test_file"
filterkey=file-key perm=0 perm_mask=2 inode=2224460 inode_uid=0
inode_gid=0 inode_dev=fd:00 inode_rdev=00:00
type=KERNEL msg=audit(1112950218.048:4070039): syscall=10 arch=40000003
success=yes exit=0 a0=bffa1bb8 a1=0 a2=80505e4 a3=bffa1bb8 items=1
pid=4543 loginuid=-1 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 comm="rm" exe=/bin/rm
- Loulwa
10:15 a.m.
On Friday 08 April 2005 10:03 am, Loulwa F Salem wrote:
linux-audit-bounces(a)redhat.com wrote on 04/06/2005 10:41:06 AM:
> I'm uploading the audit.19 kernel. It has Tim's latest patch and my
> patch to log signals sent to the audit dæmon.
>
> --
> dwmw2
>
> --
> Linux-audit mailing list
> Linux-audit(a)redhat.com
> http://www.redhat.com/mailman/listinfo/linux-audit
I am seeing an inconsistent behavior when testing the watches with this
kernel. Is anybody else encountering something similar?
Just to be clearer, we tested on my working-version of the code, and I _do_
receive records. I've not touched audit_attach/notify_watch() either.
-tim
10:34 a.m.
On Fri, 2005-04-08 at 10:15 -0500, Timothy R. Chavez wrote:
> I am seeing an inconsistent behavior when testing the watches
with this
> kernel. Is anybody else encountering something similar?
>
Just to be clearer, we tested on my working-version of the code, and I _do_
receive records. I've not touched audit_attach/notify_watch() either.
I'll double-check my backport of your code.
--
dwmw2
7:47 a.m.
On Fri, 2005-04-08 at 16:34 +0100, David Woodhouse wrote:
On Fri, 2005-04-08 at 10:15 -0500, Timothy R. Chavez wrote:
> > I am seeing an inconsistent behavior when testing the watches with this
> > kernel. Is anybody else encountering something similar?
> >
>
> Just to be clearer, we tested on my working-version of the code, and I _do_
> receive records. I've not touched audit_attach/notify_watch() either.
I'll double-check my backport of your code.
What file system are you testing on? Does it have its own permission()
routine? I put the audit_notify_watch() in vfs_permission() instead of
permission() by mistake; I'm building an audit.20 with that fixed.
--
dwmw2
7194
days inactive
7199
days old
linux-audit@lists.linux-audit.osci.io
7 comments
4 participants
participants (4)
-
David Woodhouse -
Loulwa F Salem -
Steve Grubb -
Timothy R. Chavez